Skip to main content

Last Call Review of draft-ietf-trill-multilevel-single-nickname-09

Request Review of draft-ietf-trill-multilevel-single-nickname
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-06-11
Requested 2020-05-14
Authors Mingui Zhang , Donald E. Eastlake 3rd , Radia Perlman , Margaret Cullen , Hongjun Zhai
I-D last updated 2020-05-20
Completed reviews Rtgdir Early review of -01 by Sasha Vainshtein (diff)
Rtgdir Last Call review of -11 by Sasha Vainshtein (diff)
Genart Last Call review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -09 by Samuel Weiler (diff)
Secdir Telechat review of -15 by Samuel Weiler (diff)
Genart Telechat review of -15 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-trill-multilevel-single-nickname by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 09 (document currently at 17)
Result Ready w/issues
Completed 2020-05-20
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-trill-multilevel-single-nickname-09
Reviewer: Dan Romascanu
Review Date: 2020-05-20
IETF LC End Date: 2020-06-11
IESG Telechat date: Not scheduled for a telechat


This is not easy reading for non-TRILL experts, but I can guess that this
document is useful and clear enough for the people working in the field. The
document is READY but there are a few issues that seem to be in need of being
clarified and addressed if necessary.

Major issues:

1. Something is not clear to me about the Intended Status of this document. It
is supposed to solve a problem introduced or left unclear by RFC 8243, but that
document is Informational. Why is then the Intended Status Standards Track?

Minor issues:

1. All the examples in the text are static. Changes however happen in the
configuration of the network. What happens when an Rbridge is added at the
border of an L1 area?

2. Section 6 'RB1 SHOULD use a single area nickname for all these areas.' - why
is this only a SHOULD? It seems to me that in any exception case the scheme

3. I am used with documents in the routing area to include Operational and
Manageability considerations. These are missing here, with the exception of
backwards compatibility which is addressed. Are any configuration operations
necessary for example? If these are addressed in other documents a reference
would be useful.

Nits/editorial comments:

1. Need to correct grammar/syntax problems
2. Inconsistent writing Level 1 / Level-1 ; Level 2 / Level-2
3. Section 1: s/nicknames in L2 MUST be unique/nicknames in L2 areas MUST be
unique/ 4. It would be useful to add Level to the terminology 5. Section 3.1:
s/D's location is learned by the relevant TRILL switches already/D's location
has been learned by the relevant TRILL switches already/ 6. Section 3.2:
s/ESADI protocol/ESADI protocol [RFC7357]/