Hi Mingui, I will try to summarize our agreements and disagreements. 1. The scale of TRILL deployments:
a. I have not seen any specific numbers or references to any specific topologies that could really make single-level TRILL not scalable enough - neither in the TRILL drafts I've read nor in our discussions so far b. Regarding your reference to multiple interconnected TRILL-based campuses in your last email: I do not think that TRILL is an alternative to or competes with Internet c. I have also noticed that, once upon a time (4 years ago) there was an attempt to use BGP with TRILL. I wonder why this draft has been left to expire because, from my POV, BGP is greatly preferable to multi-level IS-IS when it comes to scalability issues 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case of misunderstanding between us, probably due to the fact that I am not a TRILL expert: a. I have used the term "swapping" in the same way it is used in MPLS (e.g., see RFC 3031 discussing label swapping). In other words, from my POV "nickname swapping" and "nickname re-write" were synonyms b. It seems that some yet to be standardized extension of TRILL considers some dedicated nickname swapping mechanism that carries new nicknames in some extension of the TRILL header. In this parlance "nickname re-write" and "nickname swapping" are different c. I think that we now safely consider this discussion issue as closed 3. Metadata: a. I fully agree that we should hear from other RTG-DIR members on what exactly (if at all) should be specified to clarify the relationship between the Single Nickname draft and RFC 6325 b. I can only add that, AFAIK, the Multi-Level TRILL draft, being positioned as an Informational, can neither update nor obsolete RFC 6325 (which is Standards Track). So there is no issue with its metadata being empty. There is one issue in my original review that we have not discussed at all - namely, the behavior implied by the Single Nickname draft when a new border RBridge is added to a certain area. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: Mingui Zhang [mailto:[email protected]] Sent: Wednesday, May 25, 2016 6:07 AM To: Alexander Vainshtein Cc: '[email protected]'; Zhangxian (Xian); [email protected]; [email protected]; Susan Hares; [email protected]; Jonathan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Hi Sasha, Thanks for the comments. [[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? [Mingui] We can also doubt whether a domain with more that 2^32 IP routers is a realistic scenario. The fact is that a single campus is usually not allowed to use up the entire 64K namespace. Please consider the scenario that lots of TRILL campuses are to be interconnected. [[Sasha]] 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)? [Mingui] As I said, there is no "swap nickname field" conception in the draft. Yes, the border RBridge needs to modify the nickname but it does not have to modify it through the "swapping" operation. Instead, the border RBridge "replaces" the nickname in the TRILL data packets with its own nickname (rather than a nickname in the "swap nickname field" provided by the originating RBridge). Why authors prefer the replacing operation than the swapping operation? Because the swapping operation requires a new TRILL header (two additional 16-bit fields) which has not been standardized yet. As for the "Updates" metadata, let's see if people on the RTG-DIR list would give directions. Best regards, Mingui From: Alexander Vainshtein [mailto:[email protected]] Sent: Tuesday, May 24, 2016 6:45 PM To: Mingui Zhang Cc: '[email protected]'; Zhangxian (Xian); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Susan Hares; [email protected]<mailto:[email protected]>; Jonathan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Mingui hi! Lots of thanks for a prompt response. A few short comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> From: Mingui Zhang [mailto:[email protected]] Sent: Tuesday, May 24, 2016 11:23 AM To: Alexander Vainshtein Cc: '[email protected]'; Zhangxian (Xian); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Susan Hares; [email protected]<mailto:[email protected]>; 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:[email protected]] Sent: Monday, May 23, 2016 6:13 PM To: Mingui Zhang Cc: '[email protected]'; Zhangxian (Xian); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Susan Hares ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>; Jonathan Hardwick ([email protected]<mailto:[email protected]>) 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: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> -----Original Message----- From: rtg-dir [mailto:[email protected]] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick ([email protected]<mailto:[email protected]>) Cc: '[email protected]'; Zhangxian (Xian); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Susan Hares ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]> 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:[email protected]] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick > ([email protected]<mailto:[email protected]>) > Cc: Susan Hares ([email protected]<mailto:[email protected]>); > [email protected]<mailto:[email protected]>; Zhangxian > (Xian); > [email protected]<mailto:[email protected]>; > '[email protected]'; [email protected]<mailto:[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.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)
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
