L3VPN Any-2-Any: more detailed usage of BGPVPN API

Adding more details on how to use the existing BGPVPN API to realize the use
case. There are currently no gaps identified for this particular use case.

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

2 files changed, 84 insertions, 36 deletions

diff --git a/docs/requirements/references.rst b/docs/requirements/references.rst
index fb83ee7..b1c6b5a 100644
--- a/docs/requirements/references.rst
+++ b/docs/requirements/references.rst
@@ -9,3 +9,5 @@
 .. [MULTISITE] https://wiki.opnfv.org/display/multisite/Multisite
 .. [TRICICLE] https://wiki.openstack.org/wiki/Tricircle#Requirements
 .. [OS-NETWORKING-GUIDE-ML2] http://docs.openstack.org/mitaka/networking-guide/config-ml2-plug-in.html
+.. [RFC4364] http://tools.ietf.org/html/rfc4364
+.. [RFC7432] https://tools.ietf.org/html/rfc7432
diff --git a/docs/requirements/use_cases/l3vpn_any_to_any.rst b/docs/requirements/use_cases/l3vpn_any_to_any.rst
index 5fc5712..028e565 100644
--- a/docs/requirements/use_cases/l3vpn_any_to_any.rst
+++ b/docs/requirements/use_cases/l3vpn_any_to_any.rst
@@ -2,29 +2,38 @@
 .. http://creativecommons.org/licenses/by/4.0
 .. (c) Bin Hu
 
-Service Providers' virtualized network infrastructure may consist of one or more
-SDN Controllers from different vendors. Those SDN Controllers may be managed
-within one cloud or multiple clouds. Jointly, those VIMs (e.g. OpenStack instances)
-and SDN Controllers work together in an interoperable framework to create L3 services
-in Service Providers' virtualized network infrastructure.
+L3VPNs are virtual layer 3 networks described in multiple standards and RFCs,
+such as [RFC4364]_ and [RFC7432]_. Connectivity as well as traffic separation is
+achieved by exchanging routes between VRFs (Virtual Routing and Forwarding).
+
+Moreover, a Service Providers' virtualized network infrastructure may consist of
+one or more SDN Controllers from different vendors. Those SDN Controllers may be
+managed within one cloud or multiple clouds. Jointly, those VIMs (e.g. OpenStack
+instances) and SDN Controllers work together in an interoperable framework to
+create L3 services in the Service Providers' virtualized network infrastructure.
 
 Three use cases of creating L3VPN service by multiple SDN Controllers are described
 as follows.
 
+
 Any-to-Any Base Case
 --------------------
 
 Description
 ~~~~~~~~~~~
 
+This any-to-any use case is the base scenario, providing layer 3 connectivity
+between VNFs in the same L3VPN while separating the traffic and IP address
+spaces of different L3VPNs belonging to different tenants.
+
 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 on host B.
 
-There are 2 tenants. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and 10.3.7.0/24.
-Tenant 2 creates L3VPN Red with 1 subnet, overlapping address space: 10.1.1.0/24.
-
-The network topology is shown in :numref:`l3vpn-any2any-figure`:
+There are 2 tenants. Tenant 1 creates L3VPN Blue with 2 subnets: 10.1.1.0/24 and
+10.3.7.0/24.  Tenant 2 creates L3VPN Red with 1 subnet and an overlapping
+address space: 10.1.1.0/24. The network topology is shown in
+:numref:`l3vpn-any2any-figure`.
 
 .. figure:: images/l3vpn-any2any.png
    :name:  l3vpn-any2any-figure
@@ -38,11 +47,6 @@ and assigned IP addresses respectively.
 In L3VPN Red, VM G5 (10.1.1.5) is spawned on host A, and attached to subnet 10.1.1.0/24. VM G6
 (10.1.1.6) is spawned on host B, and attached to the same subnet 10.1.1.0/24.
 
-VRF Lets us do:
-
-1. Overlapping Addresses
-
-2. Segregation of Traffic
 
 
 Derrived Requirements
@@ -51,6 +55,8 @@ Derrived Requirements
 Northbound API / Workflow
 +++++++++++++++++++++++++
 
+[**Georg: this section needs to be made more readable**]
+
 Exemplary workflow is described as follows:
 
 1. Create Network
@@ -95,50 +101,90 @@ Current implementation
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Support for creating and managing L3VPNs is available in OpenStack Neutron by
-means of the BGPVPN project [BGPVPN]_. In order to create the L3VPN network
-configuration described above using the API BGPVPN API, the following workflow
+means of the [BGPVPN]_ project. In order to create the L3VPN network
+configuration described above using the API [BGPVPN]_ API, the following workflow
 is needed:
 
-1. Create a Neutron network "blue"
+1. Create Neutron networks for tenant "Blue"
 
-  :code:`neutron net-create blue`
+  ``neutron net-create --tenant-id Blue net1``
 
+  ``neutron net-create --tenant-id Blue net2``
 
-2. Create the first Neutron subnet of the network "blue"
 
-  :code:`neutron subnet-create <blue network UUID> 10.1.1.0/24`
+2. Create subnets for the Neutron networks for tenant "Blue"
 
+  ``neutron subnet-create --tenant-id Blue --name subnet1 net1 10.1.1.0/24``
 
-3. Create the second Neutron subnet of the network "blue"
+  ``neutron subnet-create --tenant-id Blue --name subnet2 net2 10.3.7.0/24``
 
-  :code:`neutron subnet-create <blue network UUID> 10.3.7.0/24`
 
+3. Create Neutron ports in the corresponding networks for tenant "Blue"
 
-4. Create a L3VPN by means of the BGPVPN API
+   ``neutron port-create --tenant-id Blue --name G1 --fixed-ip subnet_id=subnet1,ip_address=10.1.1.5 net1``
 
-  :code:`neutron bgpvpn-create --route-targets 64512:1 --tenant-id <tenant-id> --name blue`
+   ``neutron port-create --tenant-id Blue --name G2 --fixed-ip subnet_id=subnet1,ip_address=10.1.1.6 net1``
 
+   ``neutron port-create --tenant-id Blue --name G3 --fixed-ip subnet_id=subnet2,ip_address=10.3.7.9 net2``
 
-5. Associate the L3VPN with the previously created network
+   ``neutron port-create --tenant-id Blue --name G4 --fixed-ip subnet_id=subnet2,ip_address=10.3.7.10 net2``
 
-  :code:`neutron bgpvpn-net-assoc-create blue --network <network-UUID>`
 
-  This command associates the given Neutron network with the L3VPN. The semantic
-  of this operation is that all subnets bound to the network are getting
-  interconnected through the BGP VPN and hence VMs located in either subnet can
-  communicate with each other.
+4. Create Neutron network for tenant "Red"
 
+  ``neutron net-create --tenant-id Red net3``
 
 
-Gaps in the current solution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+5. Create subnet for the Neutron network of tenant "Red"
+
+  ``neutron subnet-create --tenant-id Red --name subnet3 net3 10.1.1.0/24``
+
+
+6. Create Neutron ports in the networks of tenant "Red"
+
+  ``neutron port-create --tenant-id Red --name G5 --fixed-ip subnet_id=subnet3,ip_address=10.1.1.5 net3``
+
+  ``neutron port-create --tenant-id Red --name G7 --fixed-ip subnet_id=subnet3,ip_address=10.1.1.6 net3``
+
+
+7. Create a L3VPN by means of the BGPVPN API for tenant "Blue"
 
-TBD
+  ``neutron bgpvpn-create --tenant-id Blue --route-targets AS:100 --name vpn1``
 
 
-Conclusion
-~~~~~~~~~~
+8. Associate the L3VPN of tenant "Blue" with the previously created networks
 
-TBD
+  ``neutron bgpvpn-net-assoc-create --tenant-id Blue --network net1 --name vpn1``
 
+  ``neutron bgpvpn-net-assoc-create --tenant-id Blue --network net2 --name vpn1``
+
+
+9. Create a L3VPN by means of the BGPVPN API for tenant "Red"
+
+  ``neutron bgpvpn-create --tenant-id Red --route-targets AS:200 --name vpn2``
+
+
+10. Associate the L3VPN of tenant "Red" with the previously created networks
+
+  ``neutron bgpvpn-net-assoc-create --tenant-id Red --network net3 --name vpn2``
+
+
+Comments:
+
+* In this configuration only one BGPVPN for each tenant is created.
+
+* The ports are associated indirectly to the VPN through their networks.
+
+* The BGPVPN backend takes care of distributing the /32 routes to the OVR instances
+  and assigning appropriate RD values.
+
+
+
+Gaps in the current solution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+There are no gaps in the currently available solution which prevent realizing
+this particular use case.
+[**Georg: there are no gaps in terms of functionality provided by the BGPVPN
+project. However, a better analysis of the multi-backend support in Neutron is
+needed**]