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.ietf@xxxxxxxxx>
Date: Friday, August 21, 2020 at 5:29 AM
To: last-call@xxxxxxxx <last-call@xxxxxxxx>
Cc: Bocci, Matthew (Nokia - GB) <matthew.bocci@xxxxxxxxx>, Vigoureux, Martin (Nokia - FR/Paris-Saclay) <martin.vigoureux@xxxxxxxxx>, bess-chairs@xxxxxxxx <bess-chairs@xxxxxxxx>, draft-ietf-bess-evpn-na-flags@xxxxxxxx <draft-ietf-bess-evpn-na-flags@xxxxxxxx>,
bess@xxxxxxxx <bess@xxxxxxxx>
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.ietf@xxxxxxxxx | Tel: +1 613 254 4814
On 2020-08-14, 12:00, "BESS on behalf of The IESG" <bess-bounces@xxxxxxxx on behalf of iesg-secretary@xxxxxxxx> 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-call@xxxxxxxx mailing lists by 2020-08-28. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/bess
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
