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)

3 files changed, 20 insertions, 9 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