Georedundancy reorganization and enhancement to the introduction

- Use case structure reorganized again
   - A new, georedundancy.rst has been created (as in L3VPN case)
   - Parent chapter (2.4) for all geuredundancy usecases added (as in L3VPN case)
- Introduction moved to the parent chapter (2.4)
- Learnings of the OPNFV Summit netready breakout added to the intro of the use cases

Change-Id: I8260269f6a2b981e9a0f226e11bed5f3cecf8b3b
Signed-off-by: csatari <gergely.csatari@nokia.com>

4 files changed, 69 insertions, 57 deletions

diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst
index 0488d69..a39e6f0 100644
--- a/docs/requirements/use_cases.rst
+++ b/docs/requirements/use_cases.rst
@@ -10,5 +10,4 @@ The following sections address networking use cases that have been identified to
     use_cases/l3vpn.rst
     use_cases/port_abstraction.rst
     use_cases/programmable_provisioning.rst
-    use_cases/georedundancy_cells.rst
-    use_cases/georedundancy_regions_insances.rst
+    use_cases/georedundancy.rst
diff --git a/docs/requirements/use_cases/georedundancy.rst b/docs/requirements/use_cases/georedundancy.rst
new file mode 100644
index 0000000..47bd9ca
--- /dev/null
+++ b/docs/requirements/use_cases/georedundancy.rst
@@ -0,0 +1,50 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Georedundancy Use Cases
+=======================
+Georedundancy refers to a configuration which ensures the service continuity of
+the VNF-s even if a whole datacenter fails [Q: Do we include or exclude VNF
+pooling?].
+
+This can be achieved by redundant VNF-s in a hot (spare VNF is running its
+configuration and internal state is synchronised to the active VNF),
+warm (spare VNF is running, its configuration is synchronised to the active VNF)
+or cold (spare VNF is not running, active VNF-s configuration is stored in a
+database and dropped to the spare VNF during its activation) standby state in a
+different datacenter from where the active VNF-s are running.
+The synchronisation and data transfer can be handled by the application or the infrastructure.
+In all of these georedundancy setups there is a need for a network connection
+between the datacenter running the active VNF and the datacenter running the
+spare VNF.
+
+In case of a distributed cloud it is possible that the georedundant cloud of an application
+is not predefined or changed and the change requires configuration in the underlay networks.
+
+This set of georedundancy use cases is about enabling the possiblity to select a datacenter as
+backup datacenter and build the connectivity between the NFVI-s in the
+different datacenters in a programmable way.
+
+As an example the following picture (:numref:`georedundancy-before`) shows a
+multicell cloud setup where the underlay network is not fully mashed.
+
+.. figure:: images/georedundancy-before.png
+    :name:  georedundancy-before
+    :width: 25%
+
+Each datacenter (DC) is a separate OpenStack cell, region or instance. Let's
+assume that a new VNF is started in DC b with a Redundant VNF in DC d. In this
+case a direct underlay network connection is needed between DC b and DC d. The
+configuration of this connection should be programable in both DC b and DC d.
+The result of the deployment is shown in the following figure
+(:numref:`georedundancy-after`):
+
+.. figure:: images/georedundancy-after.png
+   :name:  georedundancy-after
+   :width: 25%
+
+
+
+.. toctree::
+   georedundancy_cells.rst
+   georedundancy_regions_insances.rst
diff --git a/docs/requirements/use_cases/georedundancy_cells.rst b/docs/requirements/use_cases/georedundancy_cells.rst
index 95ffc6f..34269dc 100644
--- a/docs/requirements/use_cases/georedundancy_cells.rst
+++ b/docs/requirements/use_cases/georedundancy_cells.rst
@@ -1,71 +1,31 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-Georedundancy: Connection between different OpenStack cells
------------------------------------------------------------
-Georedundancy refers to a configuration which ensures the service continuity of
-the VNF-s even if a whole datacenter fails [Q: Do we include or exclude VNF
-pooling?].
-
-This can be achieved by redundant VNF-s in a hot (spare VNF is running its
-configuration and internal state is synchronised to the active VNF),
-warm (spare VNF is running, its configuration is synchronised to the active VNF)
-or cold (spare VNF is not running, active VNF-s configuration is stored in a
-database and dropped to the spare VNF during its activation) standby state in a
-different datacenter from where the active VNF-s are running.
-The synchronisation and data transfer can be handled by the application or the infrastructure.
-In all of these georedundancy setups there is a need for a network connection
-between the datacenter running the active VNF and the datacenter running the
-spare VNF.
-
-In case of a distributed cloud it is possible that the georedundant cloud of an application
-is not predefined or changed and the change requires configuration in the underlay networks.
-
-This set of georedundancy use cases is about enabling the possiblity to select a datacenter as
-backup datacenter and build the connectivity between the NFVI-s in the
-different datacenters in a programmable way.
-
-As an example the following picture (:numref:`georedundancy-before`) shows a
-multicell cloud setup where the underlay network is not fully mashed.
-
-.. figure:: images/georedundancy-before.png
-    :name:  georedundancy-before
-    :width: 25%
-
-Each datacenter (DC) is a separate OpenStack cell, region or instance. Let's
-assume that a new VNF is started in DC b with a Redundant VNF in DC d. In this
-case a direct underlay network connection is needed between DC b and DC d. The
-configuration of this connection should be programable in both DC b and DC d.
-The result of the deployment is shown in the following figure
-(:numref:`georedundancy-after`):
-
-.. figure:: images/georedundancy-after.png
-   :name:  georedundancy-after
-   :width: 25%
-
+Connection between different OpenStack cells
+--------------------------------------------
 Description
 ^^^^^^^^^^^
 There should be an API to manage the infrastructure-s networks between two
 OpenStack cells.
 (Note: In the Mitaka release of OpenStack cells v1 are considered as, cells v2
 functionaity is under implementation)
+This capability exists in the different SDN controllers, like the Add New BGP
+neighbour API of OpenDaylight. OpenStack Neutron should provide and abstracted
+API for this functionality what later calls the given SDN controllers related
+API.
 
-- Maybe the existing capability of Neutron to have several subnets associated
-  to an external network is enough?
-
-Requirements
-^^^^^^^^^^^^
+Derrived Requirements
+^^^^^^^^^^^^^^^^^^^^^
    - Possibility to define a remote and a local endpoint
    - As in case of cells the nova-api service is shared it should be possible
      to identify the cell in the API calls
 
-Northbound API / Workflow
-"""""""""""""""""""""""""
+Northbound API
+""""""""""""""
    - An infrastructure network management API is needed
    - When the endpoints are created neutron is configured to use the new network.
      (Note: Nova networking is not considered as it is deprecated.)
 
-
 Data model objects
 """"""""""""""""""
    - TBD
diff --git a/docs/requirements/use_cases/georedundancy_regions_insances.rst b/docs/requirements/use_cases/georedundancy_regions_insances.rst
index 408b425..9e74f74 100644
--- a/docs/requirements/use_cases/georedundancy_regions_insances.rst
+++ b/docs/requirements/use_cases/georedundancy_regions_insances.rst
@@ -1,17 +1,21 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-Georedundancy: Connection between different OpenStack regions or cloud instances
---------------------------------------------------------------------------------
+Connection between different OpenStack regions or cloud instances
+-----------------------------------------------------------------
 
 Description
 ^^^^^^^^^^^
 There should be an API to manage the infrastructure-s networks between two
 OpenStack regions or between two OpenStack cloud instances.
 (The only difference is the shared keystone in case of a region)
+This capability exists in the different SDN controllers, like the Add New BGP
+neighbour API of OpenDaylight. OpenStack Neutron should provide and abstracted
+API for this functionality what later calls the given SDN controllers related
+API.
 
-Requirements
-^^^^^^^^^^^^
+Derrived Requirements
+^^^^^^^^^^^^^^^^^^^^^
    - Possibility to define a remote and a local endpoint
    - Possiblity to define an overlay/segregation technology
 
@@ -21,7 +25,6 @@ Northbound API / Workflow
    - When the endpoints are created neutron is configured to use the new network.
      (Note: Nova networking is not considered as it is deprecated.)
 
-
 Data model objects
 """"""""""""""""""
    - TBD