Technical Summary
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
IPv6 addresses associated with a MAC address. Remote PEs can use
this information to populate their ARP/ND tables on IRB interfaces or
their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then
reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6
Neighbor Solicitation messages and reduce/suppress the flooding
produced by the Address Resolution procedure. However, the
information conveyed in the MAC/IP route may not be enough for the
remote PE to reply to local ARP or ND requests. For example, if a PE
learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
particular IPv6->MAC pair belongs to a host, a router or a host with
an anycast address, as this information is not carried in the EVPN
MAC/IP Advertisement routes. Similarly, other information relevant
to the IP->MAC ARP/ND entries may be needed. This document defines
an Extended Community that is advertised along with an EVPN MAC/IP
Advertisement route and carries information relevant to the ARP/ND
resolution, so that an EVPN PE implementing a proxy-ARP/ND function
can reply to ARP Requests or Neighbor Solicitations with the correct
information.
Working Group Summary
The document was developed to address the desire to minimise flooding of traffic
associated with address resolution in EVPN. It is particularly important due to the
large size that EVPN networks can grow to, particularly in terms of the numbers of CEs
and hosts. It makes use of some flags in a new BGP extended community to do this.
There are no IPR declarations on the draft .
Document Quality
This document quite well written. It represents WG consensus, and it has been widely reviewed and discussed on the list over a
number of years.
Personnel
The document shepherd is Matthew Bocci
The responsible Area Director is Martin Vigoureux