Remove references to older releases on documentation

 - Rename all Brahmaputra/Colorado links to Danube
 - Bumped OvS version from 2.5.90 to 2.6.1
 - Bumped ODL version from Boron to Boron SR2
 - Changed release date

Change-Id: I4286cbd074b377b4b33e25f33646bb05075f10f5
Signed-off-by: Juan Vidal <juan.vidal.allende@ericsson.com>
(cherry picked from commit e61239dbb4f96bb4b798cd3c6e6d6c953d4fcee4)

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