Propagation of IPv6 Neighbor Advertisement Flags in EVPN
draft-snr-bess-evpn-na-flags-02

The information below is for an old version of the document
Document Type Expired Internet-Draft (individual)
Last updated 2016-01-07 (latest revision 2015-07-06)
Replaced by draft-ietf-bess-evpn-na-flags
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-snr-bess-evpn-na-flags-02.txt

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->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.

Authors

Jorge Rabadan (jorge.rabadan@alcatel-lucent.com)
Senthil Sathappan (senthil.sathappan@alcatel-lucent.com)
Kiran Nagaraj (kiran.nagaraj@alcatel-lucent.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)