Last Call Review of draft-ietf-trill-multilevel-single-nickname-11
review-ietf-trill-multilevel-single-nickname-11-rtgdir-lc-vainshtein-2020-07-05-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document:  draft-ietf-trill--multilevel-single-nickname-11
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 02-Jul-20
IETF LC End Date: 07-Jul-20
Intended Status: Proposed Standard

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Comments:
I have done an early review of the -01 version of this draft more than 4 years
ago. I have to admit that my knowledge of TRILL has not improved since then, so
that my comments should be taken with a grain of salt by the ADs.

I have tried, to the best of my ability, to track the changes that have
happened to the draft and around it as part of my review. One of the changes
that I have noticed is publication of RFC 8423 (Informational) and RFC 8397
(Standards Track) that have been just Work in Progress at the time of my
previous review.  The former describes the motivation for multi-level TRILL and
identifies two alternative approaches for it while the latter defines the
necessary protocol extensions for one of these approaches - “unique nickname”.

One of the things that, from my POV, did not really change is readability of
the draft: it has not been easy reading then, and remains difficult to read for
the people who, like me, are not TRILL experts. I am not sure this can be much
improved, however.

The draft has been at its -09 revision when I have been selected as the
reviewer, and has advanced to -11 revision while under review:

·         the -10 revision addresses some of the issues in the Gen-Art review

·         the -11 revision has addressed some of the issues I have raised in
private discussion with the authors. I did not mention the issues that I have
raised vs. the -10 revision. I have skipped the issues that have been addressed
in the -11 version from this review.

I did not check the draft for nits. Not being a native English speaker I also
did not check for the grammar.

I would like to thank the authors, and especially Mingui, for cooperation and
patience.

Major Issues:
None found

Minor Issues:

1.       The draft updates the base TRILL spec by changing the forwarding rules
in the border RBridges, but this is not reflected in the metadata and not made
sufficiently clear in the text:

a.       I have noticed that 8397 is not marked as updating the base TRILL
spec. I have been told that the ADs feeling at the time of publication has been
that it simply extends the base spec and therefore no metadata markings are
necessary

b.       From my POV, even if 8397 may be considered as just extending the base
TRILL spec, this draft – that changes the forwarding rules specified in the
base spec -  definitely goes beyond that

c.       AFAIK  it is customary in similar cases to explicitly state in the
text (and not just in the metadata) something like “this draft updates RFC xxx
by  ...”. The sentence the authors have added to the Introduction in -11 is not
sufficiently clear from my POV

2.       As mentioned above, this draft changes the TRILL forwarding rules by
requesting the Border RBridges to replace ingress and/or egress nickname when 
a TRILL data packets traverses TRILL L2 area.

a.       My knowledge of TRILLL OAM toolbox is non-existent, but if it contains
something resembling “ping” and/or “traceroute”, change of ingress and egress
nicknames could potentially hamper such tools

b.       IMHO and FWIW, impact of the draft on the TRILL OAM tools should be at
least discussed in the draft

3.       I still have doubts regarding the problem this draft tries to solve
and its relevance

a.       To the best of my understanding, the motivation for multi-level TRILL
are scale and churn prevention. Both these issues are addressed (to some
extent) by 8397 with the scale, in theory, reaching 64K of RBridges in a single
multi-level campus

b.       Even simply saying that “this draft answers the problem of what  is
the best you can do on scaling if you ...allow change in the data plane
processing at border RBridges between Level 1 and Level 2”  would help the
readers to understand the problem this draft tries to solve IMHO

c.       Some input on the real and expected scale of TRILL campuses would also
help the readers to understand whether the solution proposed by the draft is or
is not relevant for them.

4.       I could  not understand from the  discussion of discovery in Section 5
of -011 whether such “positive” events as recovery of a link/node whose failure
has caused partitioning of a L1 area, or addition of a new Border Rbridge
between L2 and L1 areas would result in a relatively long traffic hit due to
re-discovery process or not:

a.       I do not expect such positive events to have prolonged impact on
traffic with the solution defined in 8397 (can be wrong, of course)

b.       An explicit statement, one way or another, regarding prolonged traffic
hit in the case of positive events would be useful IMHO

5.       Section 8 discusses the situation when one (or more) of the Border
RBridges of a certain L1 area supports only 8397, while one (or more) Border
RBridges of the same area support this draft.

a.       The draft says that in this case all Border RBridges of the L1 area in
question must fall back to 8397.

b.       This seems to suggest  that all RBridges that implement this draft
SHOULD (or possibly even MUST) also implement 8397; otherwise they would not to
be able to fall back to the 8397 in the case of mixed configuration as required

c.       If this understanding is correct, I think that it has to be made
explicit

6.       The text in Section 8 that says that  “duplicated {MAC, Data Label}
across these areas ought not occur ” looks as a requirement to me, but neither
MUST nor SHOULD are used. And it is not clear to me what happens if this
requirement is violated.

Hopefully, these comments will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. that is confidential and/or proprietary for the sole
use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited.  If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------