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>

7 files changed, 53 insertions, 34 deletions

diff --git a/docs/development/design/architecture.rst b/docs/development/design/architecture.rst
index 679bb2f9..98520ecf 100644
--- a/docs/development/design/architecture.rst
+++ b/docs/development/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 Colorado platform.
+OpenDaylight (ODL) SFC project into the OPNFV Danube 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 Colorado SFC:
+The following image details the Network Topology used in OPNFV Danube 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 not be finished by the time OPNFV Colorado is released, so
+work will not be finished by the time OPNFV Danube 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/development/design/requirements.rst b/docs/development/design/requirements.rst
index 1c15a9b9..6d35d946 100644
--- a/docs/development/design/requirements.rst
+++ b/docs/development/design/requirements.rst
@@ -16,15 +16,15 @@ in an OPNFV environment.
 Detailed Requirements
 +++++++++++++++++++++
 
-These are the Colorado specific requirements:
+These are the Danube specific requirements:
 
 1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE.
 
 2 The version of OVS used must support NSH.
 
-3 The SF VM life cycle will be managed by the Tacker VNF Mgr.
+3 The SF VM life cycle will be managed by the Tacker VNF Manager.
 
-4 The supported classifiers will be either ODL Netvirt or ODL GBP.
+4 The supported classifier is OpenDaylight NetVirt.
 
 5 ODL will be the OpenStack Neutron backend and will handle all networking
   on the compute nodes.
@@ -32,7 +32,7 @@ These are the Colorado specific requirements:
 Long Term Requirements
 ++++++++++++++++++++++
 
-These requirements are out of the scope of the Colorado release.
+These requirements are out of the scope of the Danube release.
 
 1 Dynamic movement of SFs across multiple Compute nodes.
 
diff --git a/docs/development/design/usecases.rst b/docs/development/design/usecases.rst
index 23e94417..cc20ecea 100644
--- a/docs/development/design/usecases.rst
+++ b/docs/development/design/usecases.rst
@@ -4,13 +4,24 @@
 Use Cases
 ---------
 
-This section outlines the Colorado use cases driving the initial OPNFV
+This section outlines the Danube use cases driving the initial OPNFV
 SFC implementation.
 
-The use cases targeted in the OPNFV SFC Colorado release focus on creating
+Use Case 1 - Two chains
+***********************
+
+This use case is  targeted 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
 Chain 2 will block SSH.
 
 .. image:: ./images/OPNFV_SFC_Brahmaputra_UseCase.jpg
+
+Use Case 2 - One chain traverses two service functions
+******************************************************
+
+This use case creates two service functions, and a chain that makes the traffic
+flow through both of them. More information is available in OPNFV-SFC wiki:
+
+https://wiki.opnfv.org/display/sfc/Functest+SFC-ODL+-+Test+2
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