From b19f458802d93ea37fc46aa6018b6c6c5586cca3 Mon Sep 17 00:00:00 2001 From: Brady Johnson Date: Wed, 7 Sep 2016 18:47:37 +0200 Subject: Update from Brahmaputra to Colorado - Patch Set 2 : fixed broken link Change-Id: Iec5356ad7fcce4b3125e117b6d14f31ca461bf5d Signed-off-by: Brady Johnson --- docs/design/architecture.rst | 6 +++--- docs/design/introduction.rst | 7 ++----- docs/design/requirements.rst | 22 +++++++++------------- docs/design/usecases.rst | 4 ++-- 4 files changed, 16 insertions(+), 23 deletions(-) (limited to 'docs') diff --git a/docs/design/architecture.rst b/docs/design/architecture.rst index d6779e9a..679bb2f9 100644 --- a/docs/design/architecture.rst +++ b/docs/design/architecture.rst @@ -5,7 +5,7 @@ Architecture ------------ This section describes the architectural approach to incorporating the upstream -OpenDaylight (ODL) SFC project into the OPNFV Brahmaputra platform. +OpenDaylight (ODL) SFC project into the OPNFV Colorado platform. Service Functions +++++++++++++++++ @@ -97,7 +97,7 @@ sequence diagram details the interactions with the VNF Mgr: OPNFV SFC Network Topology ++++++++++++++++++++++++++ -The following image details the Network Topology used in OPNFV Brahmaputra SFC: +The following image details the Network Topology used in OPNFV Colorado SFC: .. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg @@ -113,7 +113,7 @@ bridge. There is work ongoing in the upstream OVS community to implemement NSH encapsulation. To get around the way OpenStack handles VXLAN tunnels, the OVS work will also include the ability to encapsulate/decapsulate VXLAN tunnels from OpenFlow rules, instead of relying on the Vtep ports. The ongoing upstream OVS -work will probably not be finished by the time OPNFV Brahmaputra is released, so +work will not be finished by the time OPNFV Colorado is released, so a work-around has been created. This work-around will use a private branch of OVS that has a preliminary version of NSH implemented. diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst index 13584e79..f7b7df76 100644 --- a/docs/design/introduction.rst +++ b/docs/design/introduction.rst @@ -4,10 +4,7 @@ Introduction ------------ -.. NOTE:: - This is the working documentation for the SFC project. - -The `OPNFV Service Function Chaining (SFC) `_ project aims to provide the ability to define -an ordered list of a network services (e.g. firewalls, NAT, QoS). +The `OPNFV Service Function Chaining (SFC) `_ +project aims to provide the ability to define an ordered list of a network services (e.g. firewalls, NAT, QoS). These service are then "stitched" together in the network to create a service chain. This project provides the infrastructure to install the upstream ODL SFC implementation project in an NFV environment. diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst index 3a790200..1c15a9b9 100644 --- a/docs/design/requirements.rst +++ b/docs/design/requirements.rst @@ -16,29 +16,25 @@ in an OPNFV environment. Detailed Requirements +++++++++++++++++++++ -These are the Brahmaputra specific requirements: +These are the Colorado specific requirements: -1 Placement of SFs on only one Compute node will be supported. +1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE. -2 The supported Service Chaining encapsulation will be NSH VXLAN-GPE. +2 The version of OVS used must support NSH. -3 The version of OVS used must support NSH. +3 The SF VM life cycle will be managed by the Tacker VNF Mgr. -4 The SF VM life cycle will be managed by the Tacker VNF Mgr. +4 The supported classifiers will be either ODL Netvirt or ODL GBP. -5 The supported classifiers will be either ODL Netvirt or ODL GBP. - -6 ODL will be the OpenStack Neutron backend and will handle all networking +5 ODL will be the OpenStack Neutron backend and will handle all networking on the compute nodes. Long Term Requirements ++++++++++++++++++++++ -These requirements are out of the scope of the Brahmaputra release. - -1 Placing SFs on multiple Compute nodes. +These requirements are out of the scope of the Colorado release. -2 Dynamic movement of SFs across multiple Compute nodes. +1 Dynamic movement of SFs across multiple Compute nodes. -3 Load Balancing across multiple SFs +2 Load Balancing across multiple SFs diff --git a/docs/design/usecases.rst b/docs/design/usecases.rst index 0f22491d..23e94417 100644 --- a/docs/design/usecases.rst +++ b/docs/design/usecases.rst @@ -4,10 +4,10 @@ Use Cases --------- -This section outlines the Brahmaputra use cases driving the initial OPNFV +This section outlines the Colorado use cases driving the initial OPNFV SFC implementation. -The use cases targeted in the OPNFV SFC Brahmaputra release focus on creating +The use cases targeted in the OPNFV SFC Colorado release focus on creating simple Service Chains using Firewall Service Functions. As can be seen in the following diagram, 2 service chains are created, each through a different Service Function Firewall. Service Chain 1 will block HTTP, while Service -- cgit 1.2.3-korg