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

From: The IESG <[email-masked]>
Date: Fri, 14 Aug 2020 08:57:57 -0700

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
[email-masked] mailing lists by 2020-08-28. Exceptionally, comments may
be sent to [email-masked] 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.

---

From: Luc André Burdet <[email-masked]>
Date: Fri, 21 Aug 2020 03:29:18 +0000

Hi,

Apologies for writing only during WGLC, I am only just becoming familiar with this draft.

I find the Abstract and Introduction are repetitive (copy paste).
Would the authors consider shortening/rewriting the Abstract, in favour of the Introduction, to remove the duplication?

Regards,
Luc André
 
Luc André Burdet |  Cisco  |  [email-masked]  |  Tel: +1 613 254 4814

On 2020-08-14, 12:00, "BESS on behalf of The IESG" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract

    

    

    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 21 Aug 2020 07:41:41 +0000

Hi Luc,

Thanks for your email.
I think having similar text in the abstract and beginning of the introduction is not uncommon, especially if it helps people to get the gist of the document just by reading the abstract.
Nevertheless we can make all the changes that help the readability during the IESG review.

Thanks.
Jorge

From: Luc André Burdet <[email-masked]>
Date: Friday, August 21, 2020 at 5:29 AM
To: [email-masked] <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>, Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [bess] Last Call: <draft-ietf-bess-evpn-na-flags-05.txt> (Propagation of ARP/ND Flags in EVPN) to Proposed Standard
Hi,

Regards,
Luc André

    Abstract