(re-adding ovs dev list) On 07/09/2015 10:52 AM, Salvatore Orlando wrote: > > > On 8 July 2015 at 16:12, Russell Bryant <rbry...@redhat.com > <mailto:rbry...@redhat.com>> wrote: > > 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. > > > You are absolutely correct. My gut feeling (I still have to try out your > patch), is that the solution you are proposing actually does not go in > this direction. > I might be mistaken but it seems to me what we have here is a standard > logical network, implemented with overlays, that "spills" into a > physical network (and hence my suggestion on L2 gateway). > > The reference implementation (and some other open source and commercial > ones - afaict at least midonet and vmw nsx) instead implement, as you > wrote, provider networks as a different way of doing transport mappings > for a logical network.
Yes, it's my intention to implement it this way (no overlay usage at all). The code I threw up is just far from complete. The L2 gateway stuff is getting implemented too, though. Alex Wang has some patches up for that. > > > 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. > > > And we should. We might decide not to cover use cases whose usefulness > is arguable, like a provider mappings on a specific VxLAN VNI, but the > VLAN mapping is a must, and it should be implemented in the way > operators expect it to be implemented. > > > > > 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. > > > I suspect the reason for which you had not considered it is that it > would perhaps lead to an implementation that does not render the > physical network mapping in the way the reference implementation does. > > > > 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. > > > That is correct, perhaps by treating the external network as logical > port we're just moving the complexity somewhere else, but not getting > rid of it. > > > > 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. > > > Perhaps not, but at least now we're both convinced it won't! > > > -- > Russell Bryant > > -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev