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  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814
 

On 2020-08-14, 12:00, "BESS on behalf of The IESG" <bess-boun...@ietf.org on 
behalf of iesg-secret...@ietf.org> 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
    last-c...@ietf.org mailing lists by 2020-08-28. Exceptionally, comments may
    be sent to i...@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.
    
    
    
    
    
    _______________________________________________
    BESS mailing list
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess
    
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to