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**]