Reviewer: Reese Enghardt
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-nvo3-evpn-applicability-04
Reviewer: Reese Enghardt
Review Date: 2022-07-06
IETF LC End Date: 2022-07-11
IESG Telechat date: Not scheduled for a telechat
Summary: The document is well-written, though dense, and it does a good job of
breaking down a complex topic. I only found a few nits to make the document
more accessible.
Major issues: None.
Minor issues:
Abstract:
Please expand NVO3 networks on first use.
[jorge] done.
Please consider adding a sentence to already state in the abstract/introduction
that this document does not introduce any new procedures or signaling in EVPN.
[jorge] done.
If EVPN gets updated in future RFCs, does this document apply to these updates?
Not sure if it's worth saying anything about this, but I started wondering
about this question when seeing the table of EVPN route types in Section 4.1.
[jorge] it’s a good point, however I don’t think there is a need to indicate anything about it. This document describes the applicability of the existing specs to NVO3 networks.
Future EVPN extensions may or may not apply to NVO3 networks, and that will have to be detailed in the other new specifications.
Section 2:
Please expand CLOS on first use.
[jorge] I don’t think CLOS is an abbreviation, but the name used for non-blocking switching architectures like the ones in DCs, with the name coming from Charles Clos… that’s my
understanding.
Please add a definition for Tenant System, in addition to expanding the acronym.
[jorge] done
For the BT definition, not having read RFC7432, I got slightly confused
initially, as "Bridge Table" sounded to me like it's a sort-of lookup table on
a single NVE, but if it's the instantiation of a BD, it would potentially span
multiple NVEs. Having read the doc, it seems like a BT spans multiple NVEs and
potentially is the same on all NVEs in the same BD. If this is true, please
consider adding a clarifying sentence to the BT definition.
[jorge] I can see the confusion, since sometimes we use BD when we should use BT. BD really spans multiple NVEs, and BT is the instantiation in an NVE. I added this sentence to
clarify things, let me know if it is ok:
“Although a BD spans multiple NVEs, and a BT is really the instantiation of a BD in an NVE, this document uses BT and BD interchangeably.”
Section 4.2:
Figure 1 uses the terms "single-active" and "all-active", but the document only
defines/explains them in Section 4.7.5 - Is this intentional? Even though
Figure 1 uses "single-active" and "all-active", I am not seeing these terms
used in any example later on when the terms are explained. Please consider
either elaborating on how the terms relate to the Figure 1 example or removing
these terms from Figure 1.
[jorge] I added this sentence, hope it helps:
o The terms Single-Active and All-Active in Figure 1 refer to the
mode in which the TS2 and TS3 are multi-homed to the NVEs in BD1.
In All-Active mode, all the multi-homing links are active and can
send or receive traffic. In Single-Active mode, only one link (of
the set of links connected to the NVEs) is active.
Section 4.2.2:
Please consider expanding PMSI on first use.
[jorge] I added it to the terminology section.
Nits/editorial comments:
Section 4:
"The intend is" -> "The intent is"
[jorge] fixed, thanks.
