diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/requirements/use_cases/l3vpn_hub_and_spoke.rst | 116 |
1 files changed, 105 insertions, 11 deletions
diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst index 455c686..a6fec12 100644 --- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst +++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst @@ -26,6 +26,12 @@ and VNF2(S) and VNF3(S) are spawned on host B. vFW(H) (10.1.1.5) and VNF2(S) (10.1.1.6) are attached to subnet 10.1.1.0/24. VNF1(S) (10.3.7.9) and VNF3(S) (10.3.7.10) are attached to subnet 10.3.7.0/24. +Derrived Requirements +~~~~~~~~~~~~~~~~~~~~~ + +Northbound API / Workflow ++++++++++++++++++++++++++ + Exemplary vFW(H) Hub VRF is as follows: * RD1 10.1.1.5 IP_OVR1 Label1 @@ -56,15 +62,6 @@ Exemplary workflow is described as follows: 4.2. VRF Policy Resource, [H | S] - -Derrived Requirements -~~~~~~~~~~~~~~~~~~~~~ - - TBD - -Northbound API / Workflow -+++++++++++++++++++++++++ - - TBD - Data model objects ++++++++++++++++++ - TBD @@ -77,8 +74,105 @@ Dependencies on compute services ++++++++++++++++++++++++++++++++ - TBD -Potential implementation +Current implementation +++++++++++++++++++++++ + +There are multiple different technologies and corresponding projects which allow +for creating a network topology in which traffic is directed through specific +network elements. Among the projects considered here, is [BGPVPN]_ and +[NETWORKING-SFC]_. We investigate the suitability of each project in the +following. + + +BGPVPN +'''''' + +Support for creating and managing L3VPNs is in general available in OpenStack +Neutron by means of the BGPVPN project [BGPVPN]_. However, the [BGPVPN]_ API +does not allow to exactly create the hub-and-spoke topology outlined above in a +clean and straightforward manner. + +The [BGPVPN]_ API currently supports the concepts of network- and +router-associations. An association in principle maps to a VRF that +interconnects either subnets of a Neutron network (network association) or the +networks connected by a router (router association). It does not yet allow for +creating VRFs per VM port (port associations). This functionality is needed, +however, to create separate VRFs per VM. + +Given the network- and router-association mechanisms, the following workflow +establishes a network topology which aims to resemble the desired target +topology. In order to compansate for the missing port association, the basic +idea is to model separate VRFs per VM by creating a dedicated Neutron network +with two subnets for each VRF in the hub-and-spoke topology. + +1. Create Neutron network "hub" + :code:`neutron net-create hub` + +2. Create a separate Neutron network for every "spoke" + :code:`neutron net-create spoke-i` + +3. For every network (hub and spokes), create two subnets + :code:`neutron subnet-create <hub/spoke-i network UUID> 10.1.1.0/24` + :code:`neutron subnet-create <hub/spoke-i network UUID> 10.3.7.0/24` + +4. Create a BGPVPN object (VRF) for the hub network with the corresponding import + and export targets + :code:`neutron bgpvpn-create --name hub-vrf --import-targets <RT-hub RT-spoke> --export-targets <RT-hub>` + +5. Create a BGPVPN object (VRF) for every spoke network with the corresponding import + and export targets + :code:`neutron bgpvpn-create --name spoke-i-vrf --import-targets <RT-hub> --export-targets <RT-spoke>` + +6. Associate the hub network with the hub VRF + :code:`bgpvpn-net-assoc-create hub --network <hub network-UUID>` + +7. Associate each spoke network with the corresponding spoke VRF + :code:`bgpvpn-net-assoc-create spoke-i --network <spoke-i network-UUID>` + +After step 7, VMs can be booted on the corresponding networks. + +The resulting network topology resembles the target topology as shown in +:numref:`l3vpn-hub-spoke-figure`. However, the workflow for creating this +topology by means of the mechanisms provided by today's implementation deviates +significantly from the desired workflow described above. The gap analysis in the +next section investigates the describes the technical reasons for this. + +.. However, the [BGPVPN]_ API does +.. not yet support Spoke and Hub use case in terms of setting up specific VRFs of vFW(H) +.. and other VNFs(S) to create the service chain from vFW(H) to VNFs(S), +.. including those specific I-RT and E-RT at different VRFs. + + +Network SFC +''''''''''' + +Support of Service Function Chaining is in general available in OpenStack Neutron through +the Neutron API for Service Insertion and Chaining project [NETWORKING-SFC]_. +However, the [NETWORKING-SFC]_ API is focused on creating service chaining through +NSH at L2, although it intends to be agnostic of backend implementation. It is unclear whether +or not the service chain from vFW(H) to VNFs(S) can be created in the way of L3VPN-based +VRF policy approach using [NETWORKING-SFC]_ API. + +Hence, it is currently not possible to configure the networking use case as described above. + + +Gaps in Current Solution ++++++++++++++++++++++++ - - TBD +Given the use case description and the currently available implementation in +OpenStack provided by [BGPVPN]_ project and [NETWORKING-SFC]_ project, +we identify the following gaps: + +* [L3VPN-HS-GAP1] The [BGPVPN]_ project lacks port-associations + + The workflow described above intents to mimic port associations by means of + separate Neutron networks. Hence, the resulting workflow is overly complicated + and not intuitive by requiring to create additional Neutron entities + (networks) which are not present in the target topology. + + Within the [BGPVPN]_ project, design work on port-association has started. The + timeline for this feature is however not defined yet. As a result, creating a + clean hub-and-spoke topology is current not yet supported by the [BGPVPN]_ API. + +* [L3VPN-HS-GAP2] Creating a clean hub-and-spoke topology is current not yet supported by the [NETWORKING-SFC]_ API. |