Skip to main content

Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
draft-ietf-bess-evpn-na-flags-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Matthew Bocci <matthew.bocci@nokia.com>, The IESG <iesg@ietf.org>, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-na-flags@ietf.org, martin.vigoureux@nokia.com, matthew.bocci@nokia.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Propagation of ARP/ND Flags in EVPN' to Proposed Standard (draft-ietf-bess-evpn-na-flags-09.txt)

The IESG has approved the following document:
- 'Propagation of ARP/ND Flags in EVPN'
  (draft-ietf-bess-evpn-na-flags-09.txt) as Proposed Standard

This document is the product of the BGP Enabled ServiceS Working Group.

The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/


Ballot Text

Technical Summary

   An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
   IPv6 addresses associated with a MAC address.  Remote PEs can use
   this information to populate their ARP/ND tables on IRB interfaces or
   their proxy-ARP/ND tables in Broadcast Domains (BD).  PEs can then
   reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6
   Neighbor Solicitation messages and reduce/suppress the flooding
   produced by the Address Resolution procedure.  However, the
   information conveyed in the MAC/IP route may not be enough for the
   remote PE to reply to local ARP or ND requests.  For example, if a PE
   learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
   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 EVPN
   MAC/IP Advertisement routes.  Similarly, other information relevant
   to the IP->MAC ARP/ND entries may be needed.  This document defines
   an Extended Community that is advertised along with an EVPN MAC/IP
   Advertisement route and carries information relevant to the ARP/ND
   resolution, so that an EVPN PE implementing a proxy-ARP/ND function
   can reply to ARP Requests or Neighbor Solicitations with the correct
   information.

Working Group Summary

   The document was developed to address the desire to minimise flooding of traffic 
   associated with address resolution in EVPN. It is particularly important due to the
   large size that EVPN networks can grow to, particularly in terms of the numbers of CEs 
   and hosts. It makes use of some flags in a new BGP extended community to do this.

   There are no IPR declarations on the draft . 

Document Quality

   This document quite well written. It represents WG consensus, and it has been widely reviewed and discussed on the list over a 
   number of years.
   
Personnel

   The document shepherd is Matthew Bocci
   The responsible Area Director is Martin Vigoureux

RFC Editor Note