%% You should probably cite draft-ietf-bess-evpn-na-flags instead of this I-D.
@techreport{snr-bess-evpn-na-flags-07,
    number =    {draft-snr-bess-evpn-na-flags-07},
    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-na-flags/07/},
    author =    {Jorge Rabadan and Senthil Sathappan and Kiran Nagaraj},
    title =     {{Propagation of IPv6 Neighbor Advertisement Flags in EVPN}},
    pagetotal = 6,
    year =      2017,
    month =     jul,
    day =       3,
    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. However, if the Neighbor information is learnt via EVPN, the PE would not know if a 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. This document proposes an OPTIONAL advertisement of the Flags defined in {[}RFC4861{]} along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.},
}