On Wed, Mar 2, 2016 at 11:27 AM, Darrell Ball <db...@vmware.com> wrote: > > Thanks Russell > > Pls see inline > > Darrell > > > From: Russell Bryant <russ...@ovn.org> > Date: Wednesday, March 2, 2016 at 5:40 AM > To: Darrel Ball <db...@vmware.com> > Cc: Mickey Spiegel <emspi...@us.ibm.com>, Darrell Lu <dlu...@gmail.com>, " dev@openvswitch.org" <dev@openvswitch.org>, Han Zhou <zhou...@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 <db...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
