%% You should probably cite rfc9047 instead of this I-D.
@techreport{ietf-bess-evpn-na-flags-03,
    number =    {draft-ietf-bess-evpn-na-flags-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/03/},
    author =    {Jorge Rabadan and Senthil Sathappan and Kiran Nagaraj and Wen Lin},
    title =     {{Propagation of ARP/ND Flags in EVPN}},
    pagetotal = 8,
    year =      2019,
    month =     apr,
    day =       26,
    abstract =  {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 reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. 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-\textgreater{}MAC ND entry via EVPN, the PE would not know if that particular IPv6-\textgreater{}MAC pair belongs to a host, a router or a host with an anycast address, as this information is not carried in the MAC/IP route advertisements. Similarly, other information relevant to the IP-\textgreater{}MAC ARP/ND entries may be needed. This document proposes an OPTIONAL 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.},
}