Preparing files for global review

Change-Id: I5db23e973f936aace0123eb40ac24084ff1bdbce
Signed-off-by: Georg Kunz <georg.kunz@ericsson.com>

1 files changed, 0 insertions, 72 deletions

diff --git a/docs/requirements/use_cases/georedundancy.rst b/docs/requirements/use_cases/georedundancy.rst
deleted file mode 100644
index d168206..0000000
--- a/docs/requirements/use_cases/georedundancy.rst
+++ /dev/null
@@ -1,72 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Georedundancy
-=============
-Georedundancy refers to a configuration which ensures the service continuity of
-the VNF-s even if a whole datacenter fails.
-
-It is possible that the VNF application layer provides additional redundancy
-with VNF pooling on top of the georedundancy functionality described here.
-
-It is possible that either the VNFC-s of a single VNF are spread across several
-datacenters (this case is covered by the OPNFV multi-site project [MULTISITE]_
-or different, redundant VNF-s are started in different datacenters.
-
-When the different VNF-s are started in different datacenters the redundancy
-can be achieved by redundant VNF-s in a hot (spare VNF is running its
-configuration and internal state is synchronized to the active VNF),
-warm (spare VNF is running, its configuration is synchronized to the active VNF)
-or cold (spare VNF is not running, active VNF-s configuration is stored in a
-persistent, central store and configured to the spare VNF during its activation)
-standby state in a different datacenter from where the active VNF-s are running.
-The synchronization and data transfer can be handled by the application or by
-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 when the network operator uses network isolation.
-Isolation of the traffic between the datacenters might be needed due to the
-multi-tenant usage of NFVI/VIM or due to the IP pool management of the network
-operator.
-
-This set of georedundancy use cases is about enabling the possibility to select a
-datacenter as backup datacenter and build the connectivity between the NFVI-s in
-the different datacenters in a programmable way.
-
-The focus of these uses cases is on the functionality of OpenStack it is not
-considered how the provisioning of physical resources is handled by the SDN
-controllers to interconnect the two datacenters.
-
-As an example the following picture (:numref:`georedundancy-before`) shows a
-multi-cell cloud setup where the underlay network is not fully meshed.
-
-.. figure:: images/georedundancy-before.png
-    :name:  georedundancy-before
-    :width: 50%
-
-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 programmable 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: 50%
-
-.. toctree::
-   georedundancy_cells.rst
-   georedundancy_regions_insances.rst
-
-Conclusion
-----------
-  An API is needed what provides possibility to set up the local and remote
-  endpoints for the underlay network. This API present in the SDN solutions, but
-  OpenStack does not provides and abstracted API for this functionality to hide
-  the differences of the SDN solutions.