Bug 1797664

Description of problem:
I am trying to use routed provider networks with OVN and distributed compute nodes in 16.0-RC. In my setup, I have a primary physnet for the central site (datacentre) and a physnet for the edge site (edge1) to prevent issues with VLAN ID overlap. When creating an additional network segment using the edge1 physnet and the same VLAN ID, OVN does not create an additional provnet port and attempts to bind one with the 'datacentre' physnet on the edge node which does not have mappings for datacentre.

This appears to be the result of networking-ovn creating a single logical switch for all segments of a network (and thus a single provnet port per VLAN ID). Since that provnet port has the datacentre physnet from the initial network creation, binding fails on the edge nodes for the provnet port. 

Version-Release number of selected component (if applicable):
16.0 RC

Steps to Reproduce:
1. Deploy RHOSP 16 RC in a central stack with the default OVN SDN configuration, except define two physnet VLAN ranges (i.e. datacentre:2:1000,edge1:2:1000). The central stack uses the default bridge mapping of datacentre:br-ex
2. Deploy an edge stack tied to the central stack with the same physnet VLAN range configuration and a bridge mapping of edge1:br-ex
3. Create a provider network and subnet using a VLAN network from the central site
4. Create a network segment on that provider network using the same VLAN ID on the edge1 physnet that matches a network in the edge site
5. Map hosts to the appropriate host aggregates in Nova for the network segments
6. Create an instance on the provider network in the central site AZ
7. Create an instance on the provider network in the edge site AZ

Actual results:
1. The central site instance works normally and can communicate with the outside world on the provider network.
2. The edge site instance gets DHCP and metadata, but cannot communicate with the outside world.
3. Binding errors for the provnet port appear in the OVN log on the edge node.

Expected results:
Both instances should be able to communicate with the outside world.

Additional info:
A lab with this DCN setup deployed can be made available for inspection if needed.