2.2. L3VPN Use Cases

• 2.2.1. Any-to-Any Base Case
  • 2.2.1.1. Description
  • 2.2.1.2. Derived Requirements
    • 2.2.1.2.1. Northbound API / Workflow
  • 2.2.1.3. Current implementation
  • 2.2.1.4. Gaps in the current solution
• 2.2.2. L3VPN: ECMP Load Splitting Case (Anycast)
  • 2.2.2.1. Description
  • 2.2.2.2. Current implementation
    • 2.2.2.2.1. Ports with identical IP addresses
    • 2.2.2.2.2. Static Routes to ports with unique IP addresses
  • 2.2.2.3. Gaps in the current solution
  • 2.2.2.4. Conclusions
• 2.2.3. Hub and Spoke Case
  • 2.2.3.1. Description
  • 2.2.3.2. Derived Requirements
    • 2.2.3.2.1. Northbound API / Workflow
    • 2.2.3.2.2. Current implementation
      • 2.2.3.2.2.1. BGPVPN
      • 2.2.3.2.2.2. Network SFC
    • 2.2.3.2.3. Gaps in the Current Solution
      • 2.2.3.2.3.1. [L3VPN-HS-GAP1] No means to disable layer 2 semantic of Neutron networks
      • 2.2.3.2.3.2. [L3VPN-HS-GAP2] No port-association available in the BGPVPN project yet
      • 2.2.3.2.3.3. [L3VPN-HS-GAP3] No support for static routes in the BGPVPN project yet

2.2.4. Conclusion

Based on the gap analyses of the three specific L3VPN use cases we conclude that there are gaps in both the functionality provided by the BGPVPN project as well as the support for multiple backends in Neutron.

Some of the identified gaps [L3VPN-ECMP-GAP1, L3VPN-ECMP-GAP2, L3VPN-HS-GAP3] in the BGPVPN project are merely missing functionality which can be integrated in the existing OpenStack networking architecture.

Other gaps, such as the inability to explicitly disable the layer 2 semantics of Neutron networks [L3VPN-HS-GAP1] or the tight integration of ports and networks [L3VPN-HS-GAP2] hinder a clean integration of the needed functionality. In order to close these gaps, fundamental changes in Neutron or alternative approaches need to be investigated.