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>

1 files changed, 10 insertions, 50 deletions

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