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.

A few short comments inline below.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Mingui Zhang [mailto:[e-mail]]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: '[e-mail]'; Zhangxian (Xian); [e-mail]; [e-mail]; Susan Hares; [e-mail]; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname

Hi Sasha,

Thanks for your comments. Please see responses inline below.

Thanks,
Mingui

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: '[e-mail]'; Zhangxian (Xian); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Susan Hares ([e-mail]<mailto:[e-mail]>); [e-mail]<mailto:[e-mail]>; Jonathan Hardwick ([e-mail]<mailto:[e-mail]>)
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname


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]<mailto:[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]<mailto:[e-mail]>)
Cc: '[e-mail]'; Zhangxian (Xian); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Susan Hares ([e-mail]<mailto:[e-mail]>); [e-mail]<mailto:[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.



[Mingui] Yes, multi-level arch of IS-IS has already been well understood. However, the extending TRILL to multi-levels brings new challenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames and the other issue is on handling multi-destination packet distribution trees. In order not to make the specifications "abstract", the draft carefully designed two walking-through examples in Section 3. If the examples were understood, it would be non-abstract as well. ;-)



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?



[Mingui] For a single-level IS-IS instance, the length of the address determines the name space. In the informational draft, Section 1.1 TRILL Scalability Issues, the following statement is relevant

"   5. the limit of the number of TRILL switches, due to the 16-bit nickname space,"

[[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider deployment scenarios with more than 64K RBridges in a single TRILL campus? Is this a realistic scenario?





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.



[Mingui] Actually, the informational draft had included the information of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5.



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.



[Mingui] Oh, that's not true. The "Single Nickname" draft is definitely different from "Swapping Nickname" approach. In the "Single Nickname" draft, there is no "ingress swap nickname field" or "egress swap nickname field".

[[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apologies for a long quotation; the relevant places are highlighted):

    -  S transmits an Ethernet frame with source MAC = S and destination

      MAC = D.



   -  RB27 [[Sasha - the ingress RBridge]] encapsulates with a TRILL header with ingress RBridge = 27,

      and egress RBridge = 3 producing a TRILL Data packet.



   -  RB2 and RB20 have announced in the Level 1 IS-IS instance in area

      {2,20}, that they are attached to all those area nicknames,

      including {3,30}. Therefore, IS-IS routes the packet to RB2 (or

      RB20, if RB20 on the least-cost route from RB27 to RB3).



   -  RB2, when transitioning the packet from Level 1 to Level 2,

      replaces the ingress TRILL switch nickname with its own nickname,

      so replaces 27 with 2.

...



   -  The packet is forwarded through Level 2, to RB3, which has

      advertised, in Level 2, its L2 nickname as 3.



   -  RB3, when forwarding into area {3,30}, replaces the egress

      nickname in the TRILL header with RB44's nickname (44). (The

      ingress nickname MAY be replaced with an area nickname selected

      from {2,20}. See Section 4 for the detail of the selection method.

      Here, suppose nickname 2 is selected.) So, within the destination

      area, the ingress nickname will be 2 and the egress nickname will

      be 44.

In other words, your draft explicitly states that the area border RBridges modify the nicknames in the TRILL header of a packet that crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?

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



[Mingui] There is no "swapping" action in the "Single Nickname" draft. To explain with an example, if the TRILL data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" draft.

[[Sasha]] Please see above.



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



[Mingui] I think the above explanation about the difference between "Single Nickname" and "Swapping Nickname" will clear the confusion.

[[Sasha]] Sorry, but no, it doesn't.



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



[Mingui] OK. Thanks for the informational example. I am afraid the relationship between the draft and  RFC 6325 is slightly different. Since specifications of RFC 6325 would still hold after the draft is published.

[[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is not marked as obsoleting RFC 6325.



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)