On 07/07/2015 06:06 PM, Salvatore Orlando wrote: > Reading your post and the associated patch it seems that you're treating > the physical network as a logical port from a pipeline perspective but > exposing it as a logical switch attribute from a NB DB perspective. Is > that correct?
Yes, that's correct. > If my previous statement is correct, I wonder why not treat it always as > a logical port and then perhaps leverage OVN gateways? This might or > might not represent what a Neutron provider network is, but it surely > represent a viable implementation of its main use case: mapping a > logical network to a physical VLAN in the data centre, and keeping > control of security policing and IP addressing over logical ports > created on such network. Yes, using gateways to accomplish the use case from a high level makes a lot of sense and I expect to provide that, as well. The gateway work needs to make its way into OVN and then we need to figure out how to expose it from the Neutron API. My worry is that in OpenStack, there's still a significant demand for provider networks in the way the reference implementation works, without the use of any tunnels. The primary justification is simplicity, AFAICT. We don't *have* to implement this, but if we don't, it leaves a common deployment model unsatisfied by Neutron+OVN, and will continue to be covered by the reference implementation. I was hoping we could cover everything the reference implementation provides. > From what I gather this might simplify the broadcast issue you > mentioned, as you probably won't need anymore a specialised action. > We probably will still have the name overlap issue when doing neutron > integration, but this is probably an issue that can be worked around easily. > > I think the solution you propose to define mappings for the physical > network, which is very similar to Neutron's reference control plane, is > viable too and can also work in the case where the physical network is > represented as a specialised output port. Have you considered this > approach? That's interesting. I was thinking of it as a specialized output port, but as you pointed out, it's exposed as attributes on the logical switch in the NB DB. I hadn't considered defining the connectivity to the external network as a logical port. There's network-wide special handling that seemed a little easier to think about when it's configured network-wide. A logical port today exists only on a single chassis (hypervisor), while these special ports should exist on every chassis. If this is used for a given logical switch, no tunnels should be created and we need the different output behavior. So, I'm not sure if modeling it that way makes things easier. -- Russell Bryant _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
