summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorGergely Csatari <gergely.csatari@nokia.com>2016-05-13 11:11:27 +0200
committerGerrit Code Review <gerrit@172.30.200.206>2016-05-22 18:09:24 +0000
commit44a200562ce1512867c3e8ad07ef57e046f15305 (patch)
treee4f9ca0dec57eef65610a7a2ba7243fa3317f572 /docs
parent7d08ea317d3de6c291e1fa8306d256a8b3a687f8 (diff)
- Corrections based on the comments recived on the netready project meeting wk19
- Algnement of the section markups - Some more questions :) Change-Id: I0dc22f68ac501e5ae774178c6093190c2c584745 Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/requirements/use_cases/georedundancy.rst74
1 files changed, 49 insertions, 25 deletions
diff --git a/docs/requirements/use_cases/georedundancy.rst b/docs/requirements/use_cases/georedundancy.rst
index 513eee1..372230f 100644
--- a/docs/requirements/use_cases/georedundancy.rst
+++ b/docs/requirements/use_cases/georedundancy.rst
@@ -3,73 +3,97 @@
Georedundancy Use cases (Draft)
===============================
+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.
+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.
+
+This set of 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.
+
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)
+^^^^^^^^^^^
+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)
+
+- Maybe the existing capability of Neutron to have several subnets associated
+ to an external network is enough?
-Derrived Requirements
-~~~~~~~~~~~~~~~~~~~~~
+Requirements
+^^^^^^^^^^^^
- Possibility to define a remote and a local endpoint
- - Possiblity to define an overlay/segregation technology
- - As in case of cells the nova-api service is shared it should be possible to identify the cell in the API calls
+ - 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
-+++++++++++++++++++++++++
+"""""""""""""""""""""""""
- 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.)
+ - 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
Orchestration
-+++++++++++++
+"""""""""""""
- TBD
Dependencies on compute services
-++++++++++++++++++++++++++++++++
- - TBD
+""""""""""""""""""""""""""""""""
+ None.
Potential implementation
-++++++++++++++++++++++++
+""""""""""""""""""""""""
- TBD
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.
+^^^^^^^^^^^
+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)
-Derrived Requirements
-~~~~~~~~~~~~~~~~~~~~~
+Requirements
+^^^^^^^^^^^^
- Possibility to define a remote and a local endpoint
- Possiblity to define an overlay/segregation technology
Northbound API / Workflow
-+++++++++++++++++++++++++
+"""""""""""""""""""""""""
- 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.)
+ - 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
Orchestration
-+++++++++++++
+"""""""""""""
- TBD
Dependencies on compute services
-++++++++++++++++++++++++++++++++
+""""""""""""""""""""""""""""""""
- TBD
Potential implementation
-++++++++++++++++++++++++
+""""""""""""""""""""""""
- TBD
-