Subject: [bess] Barry Leiba's No Objection on draft-ietf-bess-evpn-na-flags-05: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 08 Sep 2020 20:35:10 -0700

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.

— 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.

— 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?

   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?

— Section 1.1 —
Shouldn’t “ND” also have a reference citation (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?

— 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”.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 9 Sep 2020 07:04:44 +0000

Hi Barry,

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

Thx
Jorge

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wednesday, September 9, 2020 at 5:35 AM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
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

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 —

[Jorge] changed, thanks.

[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 —
[Jorge] yes, added:

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

— Section 2 —

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 —

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Sep 2020 14:21:20 -0400

> [Jorge] I added those to the terminology section. Thanks.

Ah, but the point was to make sure they're expanded in the
Introduction, which comes before the terminology section.  We normally
prefer to have abbreviations expanded the first time they're used,
even if they're defined properly later in the document.  But use your
best judgment, and the RFC Editor will also weigh in when it's their
turn.

> [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:

I do think so, because I think the rest of the context is very
important for the Introduction, but not needed at all for the
Abstract.  The purpose of the Abstract is to have a brief description
of what the document does, so that someone reading only the title and
Abstract can know whether she should go look at the full document.  It
seems to me that this:

   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.

...is all that's needed for that purpose.  When the reader goes to the
full document, the introduction will explain the rest.

But, again, this is a non-blocking comment, and you should absolutely
use *your* best judgment on this.  I'll say no more about it, and I'm
OK with however you decide.  Thanks for considering this comment, as
well as the rest... for which your resolutions are good.

Barry

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 10 Sep 2020 10:17:51 +0000

Hi Barry,

Sounds good.
I expanded those terms in the introduction.
I also changed the abstract as you suggested.

Thank you very much!
Jorge

From: Barry Leiba <[email-masked]>
Date: Wednesday, September 9, 2020 at 8:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Re: Barry Leiba's No Objection on draft-ietf-bess-evpn-na-flags-05: (with COMMENT)

   This document defines

Barry