Public bug reported: When working with EVPN networks there are cases when you want to have the mechanism drivers understand that there is a separation between different VXLAN networks like we have with VLAN.
For my use case I have physical machines (nodes in Ironic) that are connected to two physically disconnected VXLAN fabrics. With the current VXLAN type driver I have no way to distinguish that separation like I would with VLAN based networks. There are also other requests around improved EVPN support that involve DB extensions to flag the separate network fabrics. https://bugs.launchpad.net/ovn-bgp-agent/+bug/2017890 - RFE: L2VNI support https://github.com/toreanderson/evpn_agent - provides BGP L2VNI support but needs DB extension https://github.com/datto/neutron-roth-agent - provides EVPN VXLAN for the DC but needs some workarounds The arista, juniper, and cisco mechanisms for ML2 also hack around this for VXLAN based networks. Ultimately the use case here will be for physical network support which wasn't really targeted by the original VXLAN type driver so I could understand creating a different type driver potentially instead of allowing physical_network on the current one? How my binding works (which seems to follow how others have implemented it) what would happen to a VXLAN network a mechanism driver would need to decide if the port being bound can natively participate in VXLAN via VTEP or if not a dynamic VLAN based segment is created which can then be bound to. For a L2VNI based network with these segments L2 adjacency per https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed- networks.html would still be true. While for a L3VNI network it would be false. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2105855 Title: RFE: VXLAN physical_networks or new network type Status in neutron: New Bug description: When working with EVPN networks there are cases when you want to have the mechanism drivers understand that there is a separation between different VXLAN networks like we have with VLAN. For my use case I have physical machines (nodes in Ironic) that are connected to two physically disconnected VXLAN fabrics. With the current VXLAN type driver I have no way to distinguish that separation like I would with VLAN based networks. There are also other requests around improved EVPN support that involve DB extensions to flag the separate network fabrics. https://bugs.launchpad.net/ovn-bgp-agent/+bug/2017890 - RFE: L2VNI support https://github.com/toreanderson/evpn_agent - provides BGP L2VNI support but needs DB extension https://github.com/datto/neutron-roth-agent - provides EVPN VXLAN for the DC but needs some workarounds The arista, juniper, and cisco mechanisms for ML2 also hack around this for VXLAN based networks. Ultimately the use case here will be for physical network support which wasn't really targeted by the original VXLAN type driver so I could understand creating a different type driver potentially instead of allowing physical_network on the current one? How my binding works (which seems to follow how others have implemented it) what would happen to a VXLAN network a mechanism driver would need to decide if the port being bound can natively participate in VXLAN via VTEP or if not a dynamic VLAN based segment is created which can then be bound to. For a L2VNI based network with these segments L2 adjacency per https://specs.openstack.org/openstack/neutron- specs/specs/newton/routed-networks.html would still be true. While for a L3VNI network it would be false. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2105855/+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
