Last Call Review of draft-ietf-trill-multilevel-single-nickname-09
review-ietf-trill-multilevel-single-nickname-09-genart-lc-romascanu-2020-05-20-00

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

Summary:

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
breaks

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]/