[nvo3] John Scudder's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Wed, 26 April 2023 17:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: nvo3@ietf.org
Delivered-To: nvo3@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A56C151531; Wed, 26 Apr 2023 10:15:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nvo3-evpn-applicability@ietf.org, nvo3-chairs@ietf.org, nvo3@ietf.org, Sam Aldrin <aldrin.ietf@gmail.com>, aldrin.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <168252934286.29658.14126384682318593740@ietfa.amsl.com>
Date: Wed, 26 Apr 2023 10:15:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/asROongnMDdAS0p1hSNcZeUPL8s>
Subject: [nvo3] John Scudder's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2023 17:15:43 -0000

John Scudder has entered the following ballot position for
draft-ietf-nvo3-evpn-applicability-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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

# John Scudder, RTG AD, comments for draft-ietf-nvo3-evpn-applicability-05
CC @jgscudder

Thanks for this document, I found it easy to read and understand, which is a
real credit to the authors considering the complexity of the subject matter. I
have some minor comments below which I hope may be helpful.

## COMMENTS

### Section 2, spelling of "Clos"

You've spelled "Clos" as "CLOS" as if it were an acronym. It's not, it's the
inventor's name (indeed you've cited him, [CLOS1953]) so should be spelled
mixed-case. (https://en.wikipedia.org/wiki/Clos_network,
https://en.wikipedia.org/wiki/Clos). (Also in Section 3.)

### Section 2, sorting

I found this section very useful. It looks like it started out sorted
alphabetically but the sorting falls apart part-way through? It would be even
more useful if the sorting were maintained.

### Section 2, VIDs

Seems like "VIDs" needs a definition also.

### Section 2, 2119 keyword

You have a MUST in your definition of Ethernet Tag. Since as you rightly say in
your abstract, "This document does not introduce any new procedures in EVPN",
you probably don't need that MUST, I suggest making it some plain-English word,
either "must" or "has to", for instance.

If you make that change, then you can and should remove Section 6 (the 2119
citation).

### Section 3, "fairly optimal"

"Fairly optimal" gave me a smile, if one is strict about the meaning of
"optimal" it's kind of a contradiction, like "orthogonal but related". :-) It's
clear from context so leave it if you like, fine with me, but if you want a
replacement it could be "... ECMP generally distributes utilization well across
all the links".

### Section 3, PIC ref

You might want to add a reference for PIC.

### Section 3, MAP/IP

Did you mean MAC/IP? (Also in Section 5.) If not, then please say what MAP/IP
is?

### Section 4.1, confusing description of RT-1

I don't understand what you mean by "Multi-homing: Per-ES: Mass withdrawal". I
guess maybe it means something like

        Multi-homing:
                Per-ES: Mass withdrawal
                Per-EVI: aliasing/backup

But (assuming that's right) without the additional context of
whitespace/indents, I think it's not straightforwardly or unambiguously
understandable. You might need to write this out in complete sentences.

### Section 4.3, confusing sentence

I couldn't make out what you meant by

           EVPN uses MAC/IP Advertisement and IP Prefix routes for the
   exchange of host IP routes (in the case of the MAC/IP Advertisement
   and the IP Prefix routes)

The problematic bit is the stuff in parentheses. It parses as meaning that host
routes are used in the case of IP Prefix routes, which makes no sense. This
sentence probably needs a rewrite for clarity.

### Section 4.7.2 bug in description of MAC duplication extension

I was surprised by this,

                                                the NVE may install it
   as a black-hole MAC and drop received frames with source MAC address
   and destination MAC address matching that duplicate MAC

since it implies only the case SA == DA == duplicate MAC is covered. Looking at
rfc7432bis S. 15.3, the actual condition is SA == dup MAC || DA == dup MAC, so
perhaps change the "and" to "or" in the quoted text.

Also you might as well cite the relevant section and not just rfc7432bis, to
save the reader the effort of searching for it.

Also you may want to consider rewording "black-hole" in some other way (others
may also flag this, and so might the RFC Editor).

### Section 4.7.5, ES2?

When you write ES2, did you mean ESI? (If not, what did you mean?)

### Section 4.7.6, GW

You don't expand or gloss "GW" anywhere. Yes it's pretty common usage, but I
think it bears expanding on first use.

### Section 4.7.8, "often"?

You have,

   Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must be

wouldn't it be right to insert "often", as in

   Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must often be

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments