Skip to main content

Last Call Review of draft-ietf-nvo3-evpn-applicability-04

Request Review of draft-ietf-nvo3-evpn-applicability
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-07-11
Requested 2022-06-27
Authors Jorge Rabadan , Matthew Bocci , Sami Boutros , Ali Sajassi
I-D last updated 2022-07-06
Completed reviews Rtgdir Last Call review of -03 by Mach Chen (diff)
Opsdir Last Call review of -04 by Scott O. Bradner (diff)
Genart Last Call review of -04 by Reese Enghardt (diff)
Secdir Last Call review of -04 by Kyle Rose (diff)
Assignment Reviewer Reese Enghardt
State Completed
Request Last Call review on draft-ietf-nvo3-evpn-applicability by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 04 (document currently at 06)
Result Ready w/nits
Completed 2022-07-06
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


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:

Please expand NVO3 networks on first use.
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.

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.

Section 2:
Please expand CLOS on first use.
Please add a definition for Tenant System, in addition to expanding the acronym.
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.

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.

Section 4.2.2:
Please consider expanding PMSI on first use.

Nits/editorial comments:

Section 4:
"The intend is" -> "The intent is"