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

Han Zhou zhouhan at gmail.com
Wed Mar 2 22:40:37 UTC 2016


On Wed, Mar 2, 2016 at 11:27 AM, Darrell Ball <dball at vmware.com> wrote:
>
> Thanks Russell
>
> Pls see inline
>
> Darrell
>
>
> From: Russell Bryant <russell at ovn.org>
> Date: Wednesday, March 2, 2016 at 5:40 AM
> To: Darrel Ball <dball at vmware.com>
> Cc: Mickey Spiegel <emspiege at us.ibm.com>, Darrell Lu <dlu998 at gmail.com>, "
dev at openvswitch.org" <dev at openvswitch.org>, Han Zhou <zhouhan at gmail.com>
> Subject: Re: [ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical
endpoint separation proposal
>
>
>
> 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.
>
> >> Ok, that’s fine
>
>>
>> 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?
>
> >> that would be good
>
Oops, I missed the testcase update, will add it soon.

>>
>> 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.
>
> >> agreed

Yes, in a large scale bridged mode deployment, this reduces almost 50%
number of logical ports, and corresponding logical flows.

>
>>
>> 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.
>
> >> Using the fresh new localnet approach, this will require a physical
endpoints set per logical port, which is fine
> >> maybe I’ll roll the bridge-mapping changes in sooner than later

In the new approach, Iocalnet port is realized automatically on the HVs
where there are VIF bindings of the bridged logical switch to which the
localnet port belongs. It seems not necessary to have a "physical endpoints
set". What it needs is just a VLAN id. Localnet ports for different logical
switches can share the same chassis and physical interface/bridge
information, so it would be better to have those information separately
(maybe just in chassis table) to avoid too much redundant data.


I have another concern about this logical/physical separation. Originally,
the NB/SB separation makes NB data configurable by CMS and all SB data can
be either discovered from ovn-controllers or generated according to NB
data. It was easier to manage from HA point of view, since we can keep NB
data highly consistent among copies, and SB data always regenerated upon
recovery. Now since SB data contains both configurations from CMS and data
that are dynamically generated, it may make HA more complicated. Overall I
agree with the logical/physical separation, but would it be better to keep
the configurable/dynamical data separation, too?

In addition, logical/physical doesn't map to NB/SB directly. For example,
logical flows are "logical" but resides in SB DB, because it is supposed to
be consumed by southbound interface. For my understanding NB/SB stands for
the interface that is used to access the data. CMS is NB application and
local ovn-controllers are the SB devices. With the current proposal neither
NB/SB nor logical/physical match the separation.

Darrell, could you help clarify my concern? Thank you.

--
Best regards,
Han



More information about the dev mailing list