Working on comments and document cleanup

Commenting out some of my previous comments so that they are not
part of the final document but remain in the source code. Added
conclusion to L3VPN use cases.

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

1 files changed, 16 insertions, 25 deletions

diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst
index a000046..07004ef 100644
--- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst
+++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst
@@ -19,8 +19,8 @@ Furthermore, there is no layer 2 connectivity between the VNFs.
 
 In addition, in this use case, the deployed network infrastructure comprises
 equipment from two different vendors, Vendor A and Vendor B. There are 2 hosts
-(compute nodes). SDN Controller A and vRouter A are provided by Vendor A, and
-run on host A. SDN Controller B and vRouter B are provided by Vendor B, and run
+(compute nodes). SDN Controller A and vForwarder A are provided by Vendor A, and
+run on host A. SDN Controller B and vForwarder B are provided by Vendor B, and run
 on host B.
 
 There is 1 tenant. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24.
@@ -44,21 +44,21 @@ Derived Requirements
 Northbound API / Workflow
 +++++++++++++++++++++++++
 
-[**Georg: this needs to be made more readable / explanatory**]
+.. Georg: this needs to be made more readable / explanatory
 
 Exemplary vFW(H) Hub VRF is as follows:
 
-* RD1 10.1.1.5  IP_OVR1 Label1
-* RD1 0/0 IP_OVR1 Label1
+* RD1 10.1.1.5  IP_vForwarder1 Label1
+* RD1 0/0 IP_vForwarder1 Label1
 * Label 1 Local IF (10.1.1.5)
-* RD3 10.3.7.9  IP_OVR1 Label2
-* RD2 10.1.1.6  IP_OVR2 Label3
-* RD4 10.3.7.10 IP_OVR2 Label3
+* RD3 10.3.7.9  IP_vForwarder1 Label2
+* RD2 10.1.1.6  IP_vForwarder2 Label3
+* RD4 10.3.7.10 IP_vForwarder2 Label3
 
 Exemplary VNF1(S) Spoke VRF is as follows:
 
-* RD1 0/0 IP_OVR1 Label1
-* RD3 10.3.7.9  IP_OVR1 Label2
+* RD1 0/0 IP_vForwarder1 Label1
+* RD3 10.3.7.9  IP_vForwarder1 Label2
 
 Exemplary workflow is described as follows:
 
@@ -77,10 +77,6 @@ Exemplary workflow is described as follows:
   4.2. VRF Policy Resource, [H | S]
 
 
-Data model objects
-++++++++++++++++++
-   - TBD
-
 
 Current implementation
 ++++++++++++++++++++++
@@ -95,16 +91,10 @@ BGPVPN
 ''''''
 
 Support for creating and managing L3VPNs is in general available in OpenStack
-Neutron by means of the BGPVPN API [BGPVPN]_. However, the [BGPVPN]_ API
-does not support creating the Hub-and-Spoke topology as outlined above, i.e.
-setting up specific VRFs of vFW(H) and other VNFs(S) within one L3VPN to direct
-the traffic from vFW(H) to VNFs(S).
-[**Georg: I'd like to move the last statement further down as this is already a
-conclusion without having done any kind of analysis.**]
-
-The [BGPVPN]_ API currently supports the concepts of network- and
-router-associations. An association maps Neutron network objects (networks and
-routers) to a VRF with the following semantics:
+Neutron by means of the BGPVPN API [BGPVPN]_.  The [BGPVPN]_ API currently
+supports the concepts of network- and router-associations. An association maps
+Neutron network objects (networks and routers) to a VRF with the following
+semantics:
 
 * A *network association* interconnects all subnets and ports of a Neutron
   network by binding them to a given VRF
@@ -205,7 +195,8 @@ or not the service chain from vFW(H) to VNFs(S) can be created in the way of L3V
 VRF policy approach using [NETWORKING-SFC]_ API.
 
 Hence, it is currently not possible to configure the networking use case as described above.
-**Georg: we need to look deeper into SFC to substantiate our claim here.**
+
+.. **Georg: we need to look deeper into SFC to substantiate our claim here.**
 
 
 Gaps in the Current Solution