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> 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
