[ovs-dev] OVN and OpenStack Provider Networks

[Russell Bryant]

On 06/13/2015 06:12 PM, Salvatore Orlando wrote:
>     Second, much of the flows currently programmed by ovn-controller
>     would be useful for provider networks.  We still want to implement port
>     security and ACLs (security groups).  The major difference is that
>     unless the packet is dropped by egress port security or ACLs, it should
>     be sent out the physical network and forwarded by the physical network
>     infrastructure.
> 
>     ovn-controller would need the equivalent of the current OVS agent's
>     bridge_mappings configuration option.  ovn-controller is
>     currently configured by setting values in the local Open_vSwitch
>     ovsdb database, so a similar configuration entry could be provided
>     there:
> 
>         $ ovs-vsctl set open .
>     external-ids:bridge_mappings=physnet1:br-eth1,physnet2:br-eth2
> 
>     ovn-controller would expect that the environment was pre-configured
>     with these bridges.  It would create ports on br-int that connect to
>     each bridge.
> 
>     These networks also need to be reflected in the OVN databases so that an
>     OVN logical port can be attached to a provider network.  In
>     OVN_Northbound, we could add a new table called Physical_Switch
>     that a logical port could be attached to instead of Logical_Switch.
> 
> 
> The provider network is still a logical network. I am not able to see a
> reason for having to attach a logical port to a physical switch. Can you
> explain?

Yeah, maybe the addition of "Physical_Switch" doesn't make any sense.
Now that I'm coming back to it, I'm not sure that makes as much sense as
just attributes or "Logical_Switch".

> It seems that you are trying to describe the physical network the
> logical network maps to. This makes sense, but since in Neutron then we
> also have the "multi-provider" extension, which is a generalization of
> the provider network concepts, would it make sense to consider some sort
> of logical network bindings? These bindings might express for the time
> being vlan mappings, but in the future they could be used to specify,
> for instance, VTEPs or the encap type the tenant network implements. I
> know this might be nonsense, but at first glance it seems a viable
> alternative.

That's interesting.  I need to look into what "multi-provider" provides
in more detail.

<snip some additional feedback pointing out that Physical_Switch
probably doesn't make sense>

>     This would have an impact on the OVN_Southbound database, as well.
>     No schema changes have been identified.  Entries in the Bindings
>     table would be the same, except that the UUID in the
>     logical_datapath column would refer to a Physical_Switch instead
>     of a Logical_Switch.  The contents of the Pipeline  and the
>     flows set up by ovn-controller would need to change.
> 
> 
> Would we need chassis entries also for the bridges implementing the
> mapping with physical networks, or do we consider them to be outside of
> the OVN realm?

I was proposing that info to be in the Open_vSwitch database, as that's
where the other OVN configuration entries live that are local to the
node.  I don't think the bridge mappings are useful anywhere else.

-- 
Russell Bryant