aboutsummaryrefslogtreecommitdiffstats
path: root/docs/release/scenarios/os-odl_l2-sfc-ha
diff options
context:
space:
mode:
Diffstat (limited to 'docs/release/scenarios/os-odl_l2-sfc-ha')
-rw-r--r--docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst19
1 files changed, 11 insertions, 8 deletions
diff --git a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
index cb918002..881ca967 100644
--- a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
+++ b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
@@ -5,9 +5,10 @@
Introduction
============
.. In this section explain the purpose of the scenario and the types of capabilities provided
+
The os-odl_l2-sfc-ha is intended to be used to install the OPNFV SFC project in a standard
OPNFV High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC project
-into the OPNFV environment. The OPNFV SFC Colorado release uses the OpenDaylight Boron release.
+into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight Boron SR2 release.
Scenario components and composition
===================================
@@ -72,8 +73,10 @@ Limitations, Issues and Workarounds
.. Explain scenario limitations here, this should be at a design level rather than discussing
.. faults or bugs. If the system design only provide some expected functionality then provide
.. some insight at this point.
-This scenario is not working in Colorado 1.0 with the Fuel installer, since Tacker is not
-registered in the HA Proxy and calls to Tacker fail. This will be fixed in Colorado 2.0.
+
+The *client* virtual machine needs to be located in a compute node where at least
+one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight,
+Boron, which only installs the traffic classifier in the compute nodes where the SFs are.
Specific version of OVS
-----------------------
@@ -81,8 +84,8 @@ Specific version of OVS
SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining
encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still
has not been officially merged. Previously, SFC used NSH from a branched version of OVS
-based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron release, SFC was
-changed to use a newer, branched version of OVS based on 2.5.90, called the "Yi Yang
+based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron SR2 release, SFC was
+changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang
Patch".
The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer
@@ -98,7 +101,7 @@ NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunne
are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has
been created to address this issue, which can be found here:
-http://artifacts.opnfv.org/sfc/brahmaputra/docs/design/architecture.html#ovs-nsh-patch-workaround
+http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround
In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH,
which will obviate this work around.
@@ -112,7 +115,7 @@ https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
-For more information on the OPNFV Colorado release, please visit:
+For more information on the OPNFV Danube release, please visit:
-http://www.opnfv.org/colorado
+http://www.opnfv.org/danube