%% You should probably cite draft-ietf-bess-evpn-proxy-arp-nd instead of this I-D.
@techreport{snr-bess-evpn-proxy-arp-nd-00,
    number =    {draft-snr-bess-evpn-proxy-arp-nd-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-snr-bess-evpn-proxy-arp-nd/00/},
    author =    {Jorge Rabadan and Senthil Sathappan and Kiran Nagaraj and Wim Henderickx and Thomas King and Daniel Melzer},
    title =     {{Proxy-ARP/ND function in EVPN networks}},
    pagetotal = 15,
    year =      2015,
    month =     mar,
    day =       10,
    abstract =  {The MAC/IP Advertisement route specified in {[}RFC7432{]} can optionally carry IPv4 and 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. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in {[}RFC6820{]}. This document describes how the {[}RFC7432{]} EVPN proxy-ARP/ND function should be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.},
}