Yes, it would be helpful to put this description at the beginning. Han
On Wed, Feb 3, 2016 at 2:19 PM, Amitabha Biswas <abis...@us.ibm.com> wrote: > Hi Han, > > Yes the use case for this proposal is the following (in OpenStack terms): > > "A cloud deployment where all the compute nodes are in the same L2 domain > as the 'Neutron' external network even though there may be many subnets". > There are public clouds that do meet this assumption. In such cases, there > should not be a need for a L3 gateway (resulting in one less hop). > > The modified proposal can state this use case at the beginning of the > proposal. Does this address your concern? > > Thanks > Amitabha > > > > From: Han Zhou <zhou...@gmail.com> > To: Amitabha Biswas/San Jose/IBM@IBMUS > Cc: ovs-dev <dev@openvswitch.org> > Date: 02/03/2016 11:01 AM > Subject: Re: [ovs-dev] OVN: Floating IP Support - Proposal > ------------------------------ > > > > On Mon, Feb 1, 2016 at 10:19 AM, Amitabha Biswas <*abis...@us.ibm.com* > <abis...@us.ibm.com>> wrote: > > > Packet Traversal > > ================ > > > > Inbound Packet (from external) with Floating IP Processing > > ---------------------------------------------------------- > > > > It is assumed that the ARP request for the Floating IP will be broadcast > > to > > all the hosts/hypervisors. > > > > > Hi Amitabha and Chandra, > > Thanks for the proposal! Before going to the details, we need to make the > use case clear. > > The assumption here doesn't seem to be realistic to me for most operators. > OVN overlay would most likely to be deployed on top of a IP backplane which > involves multiple L2 domains, which means it is not possible for an ARP to > be broadcast to *all* hypervisors. For relevant HVs to receive the ARP we > may schedule VMs under a given lrouter always to the HVs that are under > same L2 domain, but if we schedule VMs that way, we may lose the benefit of > overlay which is supposed to decouple the IP and location. Nevertheless, > with this limitation, this approach might still be useful if the customer > can sacrifice the IP mobility but want to utilize the metadata provided by > tunneling for east-west traffic. > > So could you define the scope and address this concern first? Otherwise we > may wait for the L3 gateway design and propose floating ip support there. > Having a dedicated L2 domain for L3 gateways and making the L3 gateways > horizontally scalable might be a more practical solution, though the > dataplane performance will have to be compromised because of the extra hops. > > -- > Best regards, > Han > > > -- Best regards, Han _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
