Propagation of IPv6 Neighbor Advertisement Flags in EVPN
draft-ietf-bess-evpn-na-flags-01

Document Type Expired Internet-Draft (bess WG)
Last updated 2018-10-11 (latest revision 2018-04-09)
Replaces draft-snr-bess-evpn-na-flags
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state WG Document
Document shepherd Matthew Bocci
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to Matthew Bocci <matthew.bocci@nokia.com>

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-ietf-bess-evpn-na-flags-01.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@nokia.com)
Senthil Sathappan (senthil.sathappan@nokia.com)
Kiran Nagaraj (kiran.nagaraj@nokia.com)

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