Polishing of georedundancy and provider network uc-s

Adding the final touch to my use cases:
   - Clarification of the introduction text in the general georedundancy capter
   - Clarification of the description of both the georedundancy and the provider networks use cases
   - Adding references.

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

1 files changed, 35 insertions, 24 deletions

diff --git a/docs/requirements/use_cases/georedundancy_cells.rst b/docs/requirements/use_cases/georedundancy_cells.rst
index 34269dc..1a98c77 100644
--- a/docs/requirements/use_cases/georedundancy_cells.rst
+++ b/docs/requirements/use_cases/georedundancy_cells.rst
@@ -4,40 +4,51 @@
 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.
+OpenStack cells. (Note: In the Mitaka release of OpenStack cells v1 are
+considered as experimental, while cells v2 functionality is under
+implementation). Cells are considered to be problematic from maintainability
+perspective as the sub-cells are using only the internal message bus and there
+is no API (and CLI) to do maintenance actions in case of a network connectivity
+problem between the main cell and the sub cells.
+
+The functionality behind the API depends on the underlying network providers (SDN
+controllers) and the networking setup.
+(For example OpenDaylight has an API to add new BGP neighbour.)
+
+OpenStack Neutron should provide an abstracted API for this functionality what
+calls the underlying SDN controllers API.
 
 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
-""""""""""""""
+Northbound API / Workflow
++++++++++++++++++++++++++
    - An infrastructure network management API is needed
+   - API call to define the remote and local infrastructure endpoints
    - 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
-""""""""""""""""""""""""""""""""
+++++++++++++++++++++++++++++++++
    None.
 
-Potential implementation
-""""""""""""""""""""""""
-   - TBD
+Data model objects
+++++++++++++++++++
+   - local and remote endpoint objects (Most probably IP addresses with some
+   additional properties).
+
+Current implementation
+~~~~~~~~~~~~~~~~~~~~~~
+  Current OpenStack implementation provides no way to set up the underlay
+  network connection.
+  OpenStack Tricicle project [TRICICLE]_
+  has plans to build up inter datacenter L2 and L3 networks.
+
+Gaps in the current solution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  An infrastructure management API is missing from Neutron where the local and
+  remote endpoints of the underlay network could be configured.