Layer 2 population (l2pop) mechanism driver implements the ML2 driver to improve
open source plugins overlay implementations (VXLAN with Linux bridge and
GRE/VXLAN with OVS)[1]. L2pop avoid the broadcast in mac learning and ARP resolution by prepopulate the bridge forwarding table[2]. However, some projects connect neutron network with outside networks, for example, project bgpvpn-networking[3] can interconnect BGP/MPLS VPNs to Openstack Neutron networks, routers and ports[3]. For the connection to the outside networks, l2pop may need to provide more information than what it does now.
This rfe proposes to add an extension registration mechanism to l2pop so that other subprojects can extend the information included in a full FDB messages before it is sent to the agent.
Problem Description
Some projects connect neutron network with outside networks. For example, project bgpvpn-networking aims at supporting inter-connection between L3VPNs and Neutron resources, i.e. Networks, Routers and Ports[4]. A typical use-case is the following: a tenant already having a BGP IP VPN (a set of external sites) setup outside the datacenter, and by using the project bgpvpn-networking they can establish the connectivity between VMs and these VPN sites.
Figure-1 illustrates an environment that an openstack deployed in the DataCenter and BGPVPN-1 is a bgp-based vpn. The openstack has enables l2pop and bgpvpn. When a vm first sends a packet to some device in the bgpvpn, broadcast for mac learning and ARP resolution can’t be avoided. The use case is listed below:
Use Case
The cloud/network admin creates BGPVPN-1 for a tenant based on contract and OSS information about the VPN for this tenant
The tenant associates BGPVPN-1 with network-1(VM-11 belongs to network-1)
The vm-11 in network-1 first sends a packet to the device-1 in BGPVPN-1.
(You can find the figure in the comment#1)
Figure-1
In the step 3, broadcast for mac learning and ARP resolution can’t be avoided. Because neutron doesn’t have the port information of the device in the bgpvpn, thus the fdbs sent by neutron won’t include the port information of the Device-1. As a result of that, before step 3, there are no flows related to Device-1 existing in the Host 1. So ARP request are sent out.
Therefore, we are introducing an extension registration mechanism which enables other subprojects such as project bgpvpn-networking can register their own function to l2pop. The registered function can add the port information in the outside networks to the fdbs. Thus the broadcast for mac learning and ARP resolution can be avoided.
Proposed Change
The idea is to add an extension registration mechanism to l2pop mech_driver.py so that other subprojects can register their own function to l2pop. A global variable l2pop_fdb_extend_funcs should be created to store the registered function by other subprojects. Function register_fdb_extend_func and run_fdb_extend_funcs should created. Function register_fdb_extend_func should be used by other subprojects to register function to l2pop. For example, project bgpvpn-networking can import the l2pop_driver by line 1 and define a new function to register its own function bgpvpn_fdb_extend_func to l2pop_driver by line 2 and 3.
1 from neutron.plugins.ml2.drivers.l2pop import mech_driver as l2pop_driver
2 def register_callbacks(self):
3 l2pop_driver.register_fdb_extend_func( constants.BGPVPN,
self.bgpvpn_fdb_extend_func)
Function run_fdb_extend_funcs should be called every time full fdbs are created. Thus the pre-registered functions stored in the global variable l2pop_fdb_extend_funcs will be called to extend the newly created fdbs. Thus subprojects can extend the information included in the fdb by such mechanism. All changes can be viewed through the link below:
https://review.openstack.org/#/q/I87450e332c1a6d8bd529eb8082292e73c533676e
Data Model Impact
None
REST API Impact
None
Command Line Client Impact
None
Other Impact
None
Other Deployer Impact
None
Performance Impact
Performance testing should be conducted to see what is the overhead of adding more information to fdb.
Implementation
Assignee(s)
Work Items
Add the register_fdb_extend_func and run_fdb_extend_funcs functions to l2pop mech_driver.py.
Add related tests.
Documentation.
Dependencies
None
Testing
Unit tests, functional tests and scenario tests are necessary.
Documentation Impact
How to register the fdb_extend_function to l2pop should be documented.
References
[1] https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/l2pop
[2] https://wiki.openstack.org/wiki/L2population_blueprint
[3] https://github.com/openstack/networking-bgpvpn
[4] https://docs.openstack.org/networking-bgpvpn/latest/user/overview.html
Can You check BP https:/
I think that Your proposal may be easier to implement if that BP would be first done.