Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 6 Jul 2020 05:02:56 +0000

Amy,
I have added another email address, [email-masked], to the list of my email addresses in the IETF DataTracker, and set it as the email address for my role of the reviewer for RtgDir.

Please let me know if anything else has to be done in this regard.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Yemin (Amy) <[email-masked]>
Sent: Monday, July 6, 2020 6:25 AM
To: Alexander Vainshtein <[email-masked]>
Subject: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Sasha,

Could you please update the email address in the your datatracker’s account, so I can do a update in the DIR list?

BR,
Amy
发件人: Alexander Vainshtein [mailto:[email-masked]]
发送时间: 2020年7月4日 0:01
收件人: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>
主题: RE: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

Amy,
Following acquisition of my employer, ECI Telecom, by Ribbon, my email address has changed from [email-masked]<mailto:[email-masked]> to [email-masked]<mailto:[email-masked]>.

I just hope this will not cause any problems with the relevant mailing lists.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Alexander Vainshtein
Sent: Friday, July 3, 2020 6:58 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yemin (Amy) <[email-masked]<mailto:[email-masked]>>
Subject: RtgDir review: draft-ietf-trill--multilevel-single-nickname-11

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<https://clicktime.symantec.com/3YECvUPzRNXUiSkLx6bewqA6H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir>

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:   [email-masked]<mailto:[email-masked]>

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