Hi Barry,

Thank you for the review.
Please see in-line with [Jorge].

Thx
Jorge

From: Barry Leiba via Datatracker <[email protected]>
Date: Wednesday, September 9, 2020 at 5:35 AM
To: The IESG <[email protected]>
Cc: [email protected] 
<[email protected]>, [email protected] 
<[email protected]>, [email protected] <[email protected]>, Bocci, Matthew (Nokia - 
GB) <[email protected]>, Bocci, Matthew (Nokia - GB) 
<[email protected]>
Subject: Barry Leiba's No Objection on draft-ietf-bess-evpn-na-flags-05: (with 
COMMENT)
Barry Leiba has entered the following ballot position for
draft-ietf-bess-evpn-na-flags-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Only minor comments here; please consider them, but there’s no need for a
detailed reply.

A number of abbreviations need to be expanded on first use, including EVPN, PE,
ND, IRB, and CE.
[Jorge] I added those to the terminology section. Thanks.


— Abstract —
The Abstract is exactly, word for word, the same as the first two paragraphs of
the Introduction, except that the Introduction helpfully splits it into two
paragraphs.  I have comments about the text below, but for the Abstract I
suggest shortening it by removing the explanatory stuff and just leaving the
summay of what this document is doing — just the final sentence looks fine, I
think.
[Jorge] I shortened and simplified it. We could leave just the last sentence, 
but then I miss some context. This is the current text, let me know if you 
still think we should just leave the last sentence:
   Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement
   routes to advertise locally learned MAC and IP addresses associated
   to host or routers.  The remote Provider Edge (PE) routers may use
   this information to populate their Address Resolution Protocol (ARP)
   or Neighbor Discovery (ND) tables and then reply locally to ARP
   Requests or Neighbor Solicitation messages on behalf of the owner of
   the IP address.  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.  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.



— Section 1 —

   An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
   IPv6 addresses associated with a MAC address.

Nit: Change “an IPv4” to just “IPv4”, I think, yes?
[Jorge] changed, thanks.


   the PE would not know if that
   particular IPv6->MAC pair belongs to a host, a router or a host with
   an anycast address

Two things here:  This is a case where a comma after “router” will really help
readability.  And isn’t “a host with an anycast address” also “a host”?  Can
you rephrase this to make the distinction between the first and third list
items clearer?
[Jorge] ok, changed to:

the PE

   would not know if that particular IPv6->MAC pair belongs to a router

   or a host, and if that address is an anycast address, as this

   information is not carried in the EVPN MAC/IP Advertisement routes.



— Section 1.1 —
Shouldn’t “ND” also have a reference citation (RFC4861)?
[Jorge] yes, added:

ND: Neighbor Discovery protocol, specified in [RFC4861].



— Section 2 —

   Bits 0-3 and 5 are not assigned by this document.

Shouldn’t this have the customary “MUST be set to zero, and ignored on receipt”
text?
[Jorge] good point. I added:

   Bits 0-3 and 5 are not assigned by this document.  They MUST be set

   to zero, and ignored on receipt.



— Section 4 —

   This will cause all the PEs in the BD
   to reply Neighbor Solicitations for the IPv6 with Neighbor
   Advertisement messages containing the wrong R and O Flags.

There’s a word missing here after “reply”: I presume the missing word is “to”.
[Jorge] I added “to” after “reply”. Thanks!



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

Reply via email to