%% You should probably cite rfc9161 instead of this I-D.
@techreport{ietf-bess-evpn-proxy-arp-nd-09,
    number =    {draft-ietf-bess-evpn-proxy-arp-nd-09},
    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-proxy-arp-nd/09/},
    author =    {Jorge Rabadan and Senthil Sathappan and Kiran Nagaraj and Greg Hankins and Thomas King},
    title =     {{Operational Aspects of Proxy-ARP/ND in EVPN Networks}},
    pagetotal = 23,
    year =      2020,
    month =     oct,
    day =       12,
    abstract =  {The EVPN MAC/IP Advertisement route can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs importing those routes in the same Broadcast Domain (BD) can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large BDs, where the amount of ARP/ND flooded traffic causes issues on connected routers and CEs. This document describes the EVPN Proxy-ARP/ND function augmented by the capability of the ARP/ND Extended Community, which together help IXPs and other operators to deal with the issues derived from Address Resolution in large BDs.},
}