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

[Russell Bryant]

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