[ovs-dev] [RFC] ovn: physical network integraiton (WIP)

[Russell Bryant]

(re-adding ovs dev list)

On 07/09/2015 10:52 AM, Salvatore Orlando wrote:
> 
> 
> On 8 July 2015 at 16:12, Russell Bryant <rbryant at redhat.com
> <mailto:rbryant at 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