Comment 1 for bug 2017890

From Tore Anderson:
I forgot to mention one thing: EVPN Type-2 MAC/IP route can optionally include an IP address, as exemplified by the advertisements from the remote VTEP here:

openstack-compute$ sudo vtysh -c 'sh bgp l2vpn evpn rd 192.02.2.4:2'
BGP table version is 7, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]:[Frag-id]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.0.2.4:2
* [2]:[0]:[48]:[00:00:5e:00:01:00]:[32]:[87.238.54.1]
                    192.0.2.35 0 64902 39029 i
                    RT:39029:99 ET:8 Default Gateway
*> 192.0.2.35 0 64901 39029 i
                    RT:39029:99 ET:8 Default Gateway
(…)
This information is useful when enabling ARP/ND suppression. The OpenStack compute node could, using this IP/MAC coupling information, answer ARP requests for 87.238.54.1 with the correct MAC locally, preventing the need to flood the ARP request packet across the L2VNI to all remote VTEPs. (Same for IPv6 Neighbour Solicitations.)

In a similar fashion, ovn-bgp-agent and/or FRR could include the IP addresses when advertising the local MAC addreses to the remote VTEPs. The MAC/IP bindings are of course known in advance since they are part of the port object in OpenStack. Advertising them would allow the remote VTEPs to suppress ARPs for VM/floating IPs/etc, answering them locally instead.

Of course, this is just a "nice-to-have" / v2.0 feature - after all, the current VLAN-based provider networks can only do flooding, so having flooding with L2VNI-based provider networks is definitively not a regression.