Thanks Russell Pls see inline
Darrell From: Russell Bryant <russ...@ovn.org<mailto:russ...@ovn.org>> Date: Wednesday, March 2, 2016 at 5:40 AM To: Darrel Ball <db...@vmware.com<mailto:db...@vmware.com>> Cc: Mickey Spiegel <emspi...@us.ibm.com<mailto:emspi...@us.ibm.com>>, Darrell Lu <dlu...@gmail.com<mailto:dlu...@gmail.com>>, "dev@openvswitch.org<mailto:dev@openvswitch.org>" <dev@openvswitch.org<mailto:dev@openvswitch.org>>, Han Zhou <zhou...@gmail.com<mailto: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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_pipermail_git_2015-2DSeptember_007480.html&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=51R7VJdSgnlV9g1a2Fsx_-eTR9Td3GNirhJsHeMmeys&s=LWvFpYg_BVvmbjxZT1mRBiAAdikjp9e6MeCGmO9TJJ0&e=> This changed within the last week. Sorry. :-) https://github.com/openvswitch/ovs/commit/6e6c3f9188a19d4e8981eb7813dd87fa54b8e882<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_commit_6e6c3f9188a19d4e8981eb7813dd87fa54b8e882&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=51R7VJdSgnlV9g1a2Fsx_-eTR9Td3GNirhJsHeMmeys&s=QsCS1pNeu5Q6wDeqQ6OkW7wpN0WR3zlTYwjK_UX3cfI&e=> 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 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 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 -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
