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

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:

    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.

    _______________________________________________
    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