Operational Aspects of Proxy-ARP/ND in EVPN Networks
draft-snr-bess-evpn-proxy-arp-nd-02

Document Type Replaced Internet-Draft (bess WG)
Last updated 2016-02-06 (latest revision 2015-10-06)
Replaced by draft-ietf-bess-evpn-proxy-arp-nd
Stream IETF
Intended RFC status Informational
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd Thomas Morin
IESG IESG state Replaced by draft-ietf-bess-evpn-proxy-arp-nd
Consensus Boilerplate Unknown
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-proxy-arp-nd-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 (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 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 may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.

Authors

Jorge Rabadan (jorge.rabadan@alcatel-lucent.com)
Senthil Sathappan (senthil.sathappan@alcatel-lucent.com)
Kiran Nagaraj (kiran.nagaraj@alcatel-lucent.com)
Wim Henderickx (wim.henderickx@alcatel-lucent.com)
Greg Hankins (greg.hankins@alcatel-lucent.com)
Thomas King (thomas.king@de-cix.net)
Daniel Melzer (daniel.melzer@de-cix.net)
Erik Nordmark (nordmark@arista.com)

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