Re: [trill] [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

[Alexander Vainshtein <[e-mail]>]

Mingui hi!

Lots of thanks for a prompt response to some of the issues I've raised in the review.



Please see some comments to you responses inline below.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



-----Original Message-----
From: rtg-dir [mailto:[e-mail]] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick ([e-mail])
Cc: '[e-mail]'; Zhangxian (Xian); [e-mail]; [e-mail]; Susan Hares ([e-mail]); [e-mail]
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname



Hi Alexander,



Thanks for the review!



The multilevel conception itself is abstract and not easily understandable.

[[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level TRILL specifically? I am asking because I believe am reasonably well aware of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSPF, but I would not call it "abstract and not easily understandable".  And there are quite a few excellent introductions to the subject (again in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review.



However, it was really interesting in designing such a solution. Appreciate the review and the time on relevant documents to figure out the whole scheme.



> ?  Nor provides any explanations about the reasons that make

> single-level IS-IS used by TRILL less scalable that single-level IS-IS

> when it is used for distributing IP reachability



The reason comes from the fact that the length of a nickname is different from an IP address.

[[Sasha]] I must admit that I do not understand the connection. By this logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-DIR list to comment on that?

I think this could be addressed in the updated version of the draft: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1.



> *         The draft positions itself as an alternative to the Aggregate

> Nicknames approach while, from my POV, it is just provides additional

> details on one of the possible flavors of this approach



The WG used to discuss several ways to address the "Aggregate Nickname" approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of any discussions that have been hold there. I am only speaking about what I could find in the two drafts mentioned in my review.

One way was to use pseudonode nickname to denote an L1 area. Another way was to let border RBridges swap L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames approach always implies swapping of ingress and egress nicknames - at least this is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit. I also do not understand how using L1 area names (which is a control plane functionality) could replace the swapping of nicknames (which is a pure data plane function).

However, these possible alternatives were never detailed as the one being reviewed, after the WG weighted their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not address the issue I've raised, namely that the Single Nickname draft incorrectly positions itself as an alternative approach to that of Aggregate Nicknames in the Multi-Level TRILL draft, and that such incorrect positioning negatively affects ability of a non-expert



> *         The draft is intended for the Standards Track, but it does not say that

> it updates the base TRILL spec (neither in the text nor in metadata)



RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS while the draft being reviewed is talking about how to enable inter-communication between level 1 IS-IS areas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 should not appear in the "Updates" metadata?

[[Sasha]] It seems that we understand the meaning of the RFC metadata differently. From my POV if  you remove/relax a restriction imposed by an already published Standards Track RFC, this means that you update it, and the metadata should reflect that. E.g., you can take a look at RFC 4379 that is marked as updating RFC 1122 because it allows transmission of IP packets with the Destination IP address  in the 127/8 subnet - something that RFC 1122 explicitly prohibits.

Again, it would be interesting to hear what the people on the RTG-DIR list (especially ones that serve now - or have served in the past - as ADs and/or WG Chairs) think on that.



Best regards,

Mingui



> -----Original Message-----

> From: Alexander Vainshtein [mailto:[e-mail]]

> Sent: Thursday, May 19, 2016 6:59 PM

> To: Jonathan Hardwick ([e-mail]<mailto:[e-mail]>)

> Cc: Susan Hares ([e-mail]<mailto:[e-mail]>); [e-mail]<mailto:[e-mail]>; Zhangxian

> (Xian); [e-mail]<mailto:[e-mail]>;

> '[e-mail]'; [e-mail]<mailto:[e-mail]>

> Subject: RTG-DIR QA review for

> draft-ietf-trill-multilevel-single-nickname

>

> Hi all,

> I have been appointed as the QA reviewer for

> draft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.o

> rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=1>.

> Before going into the review proper, I would like to make a couple of

> introductory statements.

>

>

> 1.       I am NOT a TRILL expert and actually never before has been involved

> with TRILL. I have been told that this is OK and the ADs are

> interested into getting reviews from non-experts. Well, in my case this is what they will get.

>

> 2.       The time frame for providing the review was quite demanding (at least

> for me). This probably affected the review quality and it effectively

> prevented me from discussing the review with the draft authors

> privately - I owe them a sincere apology for that.

>

> 3.       The RtgDirDocQa - Rtg Area

> Wiki<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa>

> states that the QA review is usually performed when a draft is going

> to be adopted as a WG document. While it mentions, that a WG document

> may be also subjected to such a review at the discretion of the WG

> Chairs, the initial guidelines for the QA reviewer in the Wiki mention

> only reviewing the draft for a QA adoption. As a consequence, I had to

> create my own list of questions that will try to answer based on what I have found in the Wiki. Here is this list:

>

> a.       Is the draft easily readable and understandable?

>

> b.      Does the draft represent an attempt to solve a real problem?

>

> c.       Are there some serious technical gaps that the authors should try to

> fill?

>

> d.      Are there any potential IETF process issues with the draft in its present

> form?

> Please note that the question about "a good start for a WG draft"

> which appears in the Wiki does not appear on my list (since the draft is already a WG document).

> At the same time I have included the question about solving a real

> problem (which appeared in the previous version of the Wiki page). The

> current version only asks if the draft "makes sense" which, from my POV, is something else.

>

>

> My answers to these questions follow.

>

> Is the draft easily readable and understandable?

> Of course, "easily readable and understandable" is in the eye of the beholder.

> But as a non-expert can say that it was quite difficult for me to

> understand what this draft is really about.

> Eventually, I have succeeded to build the following scheme that helped

> me to understand what I am dealing with:

>

> *         The TRILL base

> spec<https://datatracker.ietf.org/doc/rfc6325/?include_text=1>:

>

> o   Explicitly restricts TRILL to a single Level 1 IS-IS

>

> o   Explicitly states that the nicknames of RBridges in the Trill packet header

> remain unchanged when the packet traverses the TRILL domain from

> ingress (where the TRILL header is pushed on the original Ethernet

> frame) to egress (where this header is popped)

>

> *         An Informational Multi-Level

> TRILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> evel/?include _text=1> WG draft claims that this restriction

> negatively affects TRILL scalability:

>

> o   It mentions several scalability issues

>

> o   However, it

>

> ?  Neither mentions any specific scale parameters where these issues

> become real

>

> ?  Nor provides any explanations about the reasons that make

> single-level IS-IS used by TRILL less scalable that single-level IS-IS

> when it is used for distributing IP reachability

>

> o   It claims that some of these issues may be addressed by allowing usage of

> multi-level IS-IS for TRILL

>

> o   It provides two specific proposals for making multi-level TRILL work:

>

> o   One of these proposals is called "unique nicknames". This proposal:

>

> ?   Does not require any changes in the TRILL data plane

>

> ?  Requires introducing some structure in the nicknames of RBridges in

> order to guarantee that these names are unique within the TRILL-based

> campus

>

> o   The other proposal is called "aggregate nicknames". This proposal:

>

> ?  Allows RBridges in different L1 areas of the campus to share

> nicknames

>

> ?  Requires a change in the TRILL data plane: the nicknames in the

> TRILL header of a packet will be modified by the L12 RBridges

>

> ?  Allows two possible flavors (bot mentioned in the draft):

>

> *         The flavor that uses L1 area nicknames

>

> *         The flavor that uses the nicknames of all L12 RBridges connected to a

> given L1 area as its name

>

> *         The Standards Track Single Nickname draft (one that I have been

> asked to review) provides details on the second of the above-mentioned

> flavors of the "Aggregate Nicknames" approach:

>

> o   It also allows sharing the same nickname between RBridges in different L1

> areas

>

> o   It also requires the same change in the TRILL data plane

>

> o   It eliminates the need for allocating nicknames to L1 areas. Instead, each

> such area is identified by the set of nicknames of all L12 RBridges

> that connect to it.

> It took me quite some time to build this scheme, and the text in the

> draft was not very helpful in this.

> The following points contributed to "negative readability" from my POV:

>

> *         The draft positions itself as an alternative to the Aggregate

> Nicknames approach while, from my POV, it is just provides additional

> details on one of the possible flavors of this approach

>

> *         The draft is intended for the Standards Track, but it does not say that

> it updates the base TRILL spec (neither in the text nor in metadata)