[ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint separation proposal

[Russell Bryant]

On Tue, Mar 1, 2016 at 11:27 PM, Darrell Ball <dball at vmware.com> wrote:

> Hi Mickey
>
> I was going with the assumption that the “localnet” logical port on each
> HV has a unique name linked to HV/logical switch tuple
> Localnet configuration uses multiple logical switches to support a single
> localnet.
>
> My reference to base this assumption on was this link
> http://openvswitch.org/pipermail/git/2015-September/007480.html
>

This changed within the last week.  Sorry.  :-)

https://github.com/openvswitch/ovs/commit/6e6c3f9188a19d4e8981eb7813dd87fa54b8e882

We worked out an acceptable way to model connectivity to a localnet with a
single logical switch.


> Also, if you check the OVN tests for localnet, the configuration uses the
> same approach.
>

Oops.  This should have been changed when the above patch merged.  Han, is
this something you could look at doing?


> If this assumption holds, then even for localnet, a logical port is only
> bound to a single physical endpoint (chassis/port/encap)
>
> I think you are suggesting that a single logical port name for a localnet
> network be used across the HVs ?
>
> Then the logical port becomes a single name, such as your example below - provnet1-physnet1
>
> I understand the advantage of a using a single logical port name in some cases, as it slightly simplifies the configuration at the NB,
>
> although we would still need to configure each HV access point uniquely with ovs-vsctl for physical endpoints then.
>
>
> However, in general, I think there may be some reasons to retain the unique logical port names for localnet access points -
>
> to support different addresses and port security per logical access point, per the NB schema.
>
>
> Let me know if you think being able to have a single localnet logical port name across
>
> hypervisors is a hard requirement.
>
> It is, based on the current state of the code.  It helped simplify the
OpenStack Neutron plugin a lot.  It also drastically reduces the number of
logical flows needed to model many ports connected to a localnet.


> I think the explicit bridge-mapping for localnet could be eliminated.
>
> The network_name is associated with a logical port and a
>
> logical port is bound to a physical endpoint chassis, which is the
>
> localnet access bridge….
>
> However, I did not mention it in this patch, because for localnet,
>
>  I just wanted to focus on the encapsulation/tag for now.
>
> Yes, I think moving the bridge mappings info into southbound is a nice
improvement. We've come across a case where we need to know this
information in our OpenStack Neutron plugin, so I was hoping that we'd be
able to read it from the southbound database as a nice side effect of this
work.

-- 
Russell Bryant