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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi John,

Thank you very much for reviewing. As usual, great points.

Version 06 addresses your comments.

Please see in-line for our comments.

Thanks.
Jorge

From: John Scudder via Datatracker <[e-mail]>
Date: Wednesday, April 26, 2023 at 7:15 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Sam Aldrin <[e-mail]>, [e-mail] <[e-mail]>
Subject: John Scudder's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



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.)
[jorge] agreed. Changed.


### 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.
[jorge] ordered reviewed and changed.


### Section 2, VIDs

Seems like "VIDs" needs a definition also.
[jorge] added.


### 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).
[jorge] good point, this was also mentioned by Lars. Fixed now, and boilerplate text removed.


### 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".
[jorge] you’re absolutely right :-) I took your suggestion.


### Section 3, PIC ref

You might want to add a reference for PIC.
[jorge] done


### Section 3, MAP/IP

Did you mean MAC/IP? (Also in Section 5.) If not, then please say what MAP/IP
is?
[jorge] yup, MAC/IP. Fixed now.


### 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.
[jorge] done. Hopefully it reads better now.


### 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.
[jorge] I agree. I rewrote the sentence as:
“EVPN uses MAC/IP Advertisement routes for the exchange of host IP routes and IP Prefixes routes for the exchange of prefixes of any length (including host routes too).”


### 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).
[jorge] I fixed all the above, thanks. I used “drop-MAC” instead of black-hole, since we used that in other documents when this was flagged by the RFC Editor.


### Section 4.7.5, ES2?

When you write ES2, did you mean ESI? (If not, what did you mean?)
[jorge] I changed it to ESI-2 to be consistent with the figure. Thx.


### 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.
[jorge] done


### 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
[jorge] done


## 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