Public bug reported: 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. +------------------------------+ +------------+ +----------+ | DataCenter | | WAN | | BGPVPN-1 | | +----+ +----+ +----+ +----+ | | |CE-1+-------- +PE-1| |PE-2+---------+CE-2| | | +----+ +----+ +----+ +----+ | |+----------------------------+| | | |+--------+| || Host 0 || +------------+ ||Device-1|| || +-----+ +-----+ +-----+ || |+--------+| || |VM-01| |VM-02|...|VM-0m| || | | || +-----+ +-----+ +-----+ || |+--------+| |+----------------------------+| ||Device-2|| | | |+--------+| |+----------------------------+| | . | || Host 1 || | . | || +-----+ +-----+ +-----+ || | . | || |VM-11| |VM-12|...|VM-1p| || |+--------+| || +-----+ +-----+ +-----+ || ||Device-t|| |+----------------------------+| |+--------+| | . | | | | . | +----------+ | . | |+----------------------------+| || Host n || || +-----+ +-----+ +-----+ || || |VM-n1| |VM-n2|...|VM-nq| || || +-----+ +-----+ +-----+ || |+----------------------------+| +------------------------------+ 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 ** Affects: neutron Importance: Undecided Status: New ** Description changed: 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. - +------------------------------+ +------------+ +----------+ - | DataCenter | | WAN | | BGPVPN-1 | - | +----+ +----+ +----+ +----+ | - | |CE-1+-------- +PE-1| |PE-2+---------+CE-2| | - | +----+ +----+ +----+ +----+ | - |+----------------------------+| | | |+--------+| - || Host 0 || +------------+ ||Device-1|| - || +-----+ +-----+ +-----+ || |+--------+| - || |VM-01| |VM-02|...|VM-0m| || | | - || +-----+ +-----+ +-----+ || |+--------+| - |+----------------------------+| ||Device-2|| - | | |+--------+| - |+----------------------------+| | . | - || Host 1 || | . | - || +-----+ +-----+ +-----+ || | . | - || |VM-11| |VM-12|...|VM-1p| || |+--------+| - || +-----+ +-----+ +-----+ || ||Device-t|| - |+----------------------------+| |+--------+| - | . | | | - | . | +----------+ - | . | - |+----------------------------+| - || Host n || - || +-----+ +-----+ +-----+ || - || |VM-n1| |VM-n2|...|VM-nq| || - || +-----+ +-----+ +-----+ || - |+----------------------------+| - +------------------------------+ - - Figure-1 + +------------------------------+ +------------+ +----------+ + | DataCenter | | WAN | | BGPVPN-1 | + | +----+ +----+ +----+ +----+ | + | |CE-1+-------- +PE-1| |PE-2+---------+CE-2| | + | +----+ +----+ +----+ +----+ | + |+----------------------------+| | | |+--------+| + || Host 0 || +------------+ ||Device-1|| + || +-----+ +-----+ +-----+ || |+--------+| + || |VM-01| |VM-02|...|VM-0m| || | | + || +-----+ +-----+ +-----+ || |+--------+| + |+----------------------------+| ||Device-2|| + | | |+--------+| + |+----------------------------+| | . | + || Host 1 || | . | + || +-----+ +-----+ +-----+ || | . | + || |VM-11| |VM-12|...|VM-1p| || |+--------+| + || +-----+ +-----+ +-----+ || ||Device-t|| + |+----------------------------+| |+--------+| + | . | | | + | . | +----------+ + | . | + |+----------------------------+| + || Host n || + || +-----+ +-----+ +-----+ || + || |VM-n1| |VM-n2|...|VM-nq| || + || +-----+ +-----+ +-----+ || + |+----------------------------+| + +------------------------------+ + + 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) + 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 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1793653 Title: [RFE] Enable other projects to extend l2pop fdb information Status in neutron: New Bug description: 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. +------------------------------+ +------------+ +----------+ | DataCenter | | WAN | | BGPVPN-1 | | +----+ +----+ +----+ +----+ | | |CE-1+-------- +PE-1| |PE-2+---------+CE-2| | | +----+ +----+ +----+ +----+ | |+----------------------------+| | | |+--------+| || Host 0 || +------------+ ||Device-1|| || +-----+ +-----+ +-----+ || |+--------+| || |VM-01| |VM-02|...|VM-0m| || | | || +-----+ +-----+ +-----+ || |+--------+| |+----------------------------+| ||Device-2|| | | |+--------+| |+----------------------------+| | . | || Host 1 || | . | || +-----+ +-----+ +-----+ || | . | || |VM-11| |VM-12|...|VM-1p| || |+--------+| || +-----+ +-----+ +-----+ || ||Device-t|| |+----------------------------+| |+--------+| | . | | | | . | +----------+ | . | |+----------------------------+| || Host n || || +-----+ +-----+ +-----+ || || |VM-n1| |VM-n2|...|VM-nq| || || +-----+ +-----+ +-----+ || |+----------------------------+| +------------------------------+ 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 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1793653/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
