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 <laburdet.i...@gmail.com> Date: Friday, August 21, 2020 at 5:29 AM To: last-c...@ietf.org <last-c...@ietf.org> Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>, Vigoureux, Martin (Nokia - FR/Paris-Saclay) <martin.vigour...@nokia.com>, bess-cha...@ietf.org <bess-cha...@ietf.org>, draft-ietf-bess-evpn-na-fl...@ietf.org <draft-ietf-bess-evpn-na-fl...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: Re: [bess] Last Call: <draft-ietf-bess-evpn-na-flags-05.txt> (Propagation of ARP/ND Flags in EVPN) to Proposed Standard 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