Comment 24 for bug 1545897

@Amitabha, What I meant by was the following:

Currently, If a VM (IP,mac) on the logical-switch for provider-network sends a broadcast gratuitous ARP request, then OVN on the same hypervisor responds to that ARP request without flooding it out onto the localnet physical network.
This behavior needs to change.

Try the following test from your VM (IP) on a provider network.

case 1)
arping -U -c 1 -I eth1 IP (request mode to update neighbors)
 -- You will see a response from OVN, and not flooded to provider net

case 2)
arping -D -c 1 -I eth1 IP (ARP Probing for Duplicate Address Detection)
-- you will see a response from OVN, and not flooded to provider net

case 3)
arping -A -c1 -I eth1 IP (answer mode to update neighbors)
-- you will not see a response from OVN, and you will see this flooded to provider net

In cases 1 and 2 above, I believe OVN is behaving wrongly for provider network,
In both of those cases, a) OVN should not respond, and b) It should flood the request onto
localnet

Cases 1) and 2) above are used in practice in the following ways.
Case 1) is used in VRRP for example -
https://tools.ietf.org/html/rfc3768 (section 6.4.1)

and Case 2) is used for ARP probing for duplicate address detection - see:
https://tools.ietf.org/html/rfc5227#section-2

But, the above usecase may not apply to the usecases OVN is targeted for and so, this
may not be a serious problem.