Hi Alexander, Thanks for the review!
The multilevel conception itself is abstract and not easily understandable. 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. 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. One way was to use pseudonode nickname to denote an L1 area. Another way was to let border RBridges swap L1 and L2 nicknames. However, these possible alternatives were never detailed as the one being reviewed, after the WG weighted their issues and complexity. > * 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? Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:[email protected]] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick ([email protected]) > Cc: Susan Hares ([email protected]); [email protected]; Zhangxian (Xian); > [email protected]; '[email protected]'; > [email protected] > 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.org/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-multilevel/?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) _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
