Last Call: <draft-ietf-bess-evpn-na-flags-05.txt> (Propagation of ARP/ND Flags in EVPN) to Proposed Standard

The IESG <iesg-secretary@ietf.org> Fri, 14 August 2020 15:57 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Last Call: <draft-ietf-bess-evpn-na-flags-05.txt> (Propagation of ARP/ND Flags in EVPN) to Proposed Standard
Auto-Submitted: auto-generated
Precedence: bulk
CC: matthew.bocci@nokia.com, bess@ietf.org, Matthew Bocci <matthew.bocci@nokia.com>, draft-ietf-bess-evpn-na-flags@ietf.org, bess-chairs@ietf.org, martin.vigoureux@nokia.com
Reply-To: last-call@ietf.org
Sender: iesg-secretary@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <159742067794.10178.1301710214688840563@ietfa.amsl.com>
Date: Fri, 14 Aug 2020 08:57:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/sDGTinpc3xcouKpQdIA5Ipw2lUU>

The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Propagation of ARP/ND Flags in EVPN'
  <draft-ietf-bess-evpn-na-flags-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/



No IPR declarations have been submitted directly on this I-D.

Last Call: <draft-ietf-bess-evpn-na-flags-05.txt>… The IESG