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>

4 files changed, 33 insertions, 25 deletions

diff --git a/docs/release/configguide/feature.configuration.rst b/docs/release/configguide/feature.configuration.rst
index f5502082..8bd39436 100644
--- a/docs/release/configguide/feature.configuration.rst
+++ b/docs/release/configguide/feature.configuration.rst
@@ -12,9 +12,9 @@ SFC feature desciription
 For details of the scenarios and their provided capabilities refer to
 the scenario description documents:
 
-- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html
+- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-ha/index.html
 
-- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html
+- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-noha/index.html
 
 
 The SFC feature enables creation of Service Fuction Chains - an ordered list
@@ -68,7 +68,7 @@ Pre-configuration activites - Preparing the host to install Fuel by script
 .. instructions applicable to the deploy tool used in the scenario.
 
 Before starting the installation of the SFC scenarios some preparation of the
-machine that will host the Colorado Fuel cluster must be done.
+machine that will host the Danube Fuel cluster must be done.
 
 Installation of required packages
 ---------------------------------
@@ -99,17 +99,17 @@ CI is deploying the scenario.
 First of all the opnfv-fuel repository needs to be cloned:
 ::
 
- git clone -b 'stable/colorado' ssh://<user>@gerrit.opnfv.org:29418/fuel
+ git clone -b 'stable/danube' ssh://<user>@gerrit.opnfv.org:29418/fuel
 
-This command copies the whole colorado branch of repository fuel.
+This command copies the whole danube branch of repository fuel.
 
 Now download the appropriate OPNFV Fuel ISO into an appropriate folder:
 ::
 
- wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso
+ wget http://artifacts.opnfv.org/fuel/danube/opnfv-danube.1.0.iso
 
 The exact name of the ISO image may change.
-Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO.
+Check https://www.opnfv.org/opnfv-danube-fuel-users to get the latest ISO.
 
 Simplified scenario deployment procedure using Fuel
 ===================================================
@@ -242,7 +242,7 @@ Openvswitch are not provided install them by:
 
 If plugins are installed and you want to update them use --force flag.
 
-Note that One may inject other - Colorado compatible - plugins to the Fuel
+Note that One may inject other - Danube compatible - plugins to the Fuel
 Master host using the command scp:
 
 scp <plugin>.rpm root@10.20.0.2:<plugin>.rpm
diff --git a/docs/release/release-notes/releasenotes.rst b/docs/release/release-notes/releasenotes.rst
index 3e37b6d7..f73e6672 100644
--- a/docs/release/release-notes/releasenotes.rst
+++ b/docs/release/release-notes/releasenotes.rst
@@ -55,7 +55,7 @@ Release Data
 | **Release designation**              | Danube base release                  |
 |                                      |                                      |
 +--------------------------------------+--------------------------------------+
-| **Release date**                     | March 27 2017                        |
+| **Release date**                     | March 31 2017                        |
 |                                      |                                      |
 +--------------------------------------+--------------------------------------+
 | **Purpose of the delivery**          | Add two new test cases and improve   |
@@ -86,7 +86,7 @@ the following documentation:
 
 - `User Guide <http://artifacts.opnfv.org/sfc/danube/docs/userguide/index.html>`_
 
-- `Installation Instructions <http://artifacts.opnfv.org/sfc/colorado/docs/installationprocedure/index.html>`_
+- `Installation Instructions <http://artifacts.opnfv.org/sfc/danube/docs/installationprocedure/index.html>`_
 
 - Release notes (This document)
 
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
 
diff --git a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
index b5d41044..74d386b0 100644
--- a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
+++ b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
@@ -5,10 +5,11 @@
 Introduction
 ============
 .. In this section explain the purpose of the scenario and the types of capabilities provided
+
 The os-odl_l2-sfc-noha is intended to be used to install the OPNFV SFC project in a standard
 OPNFV Non-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.
+project into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight
+Boron SR2 release.
 
 Scenario components and composition
 ===================================
@@ -75,14 +76,18 @@ Limitations, Issues and Workarounds
 .. faults or bugs.  If the system design only provide some expected functionality then provide
 .. some insight at this point.
 
+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
 -----------------------
 
 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 +103,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 +117,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