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, 50 insertions, 0 deletions

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