[ovs-dev] OVN: Floating IP Support - Proposal

[Amitabha Biswas]

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 <zhouhan at gmail.com>
To:     Amitabha Biswas/San Jose/IBM at IBMUS
Cc:     ovs-dev <dev at 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 <abiswas at 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