Hi Julien, Thanks a lot for the careful review. We will improve the draft as you suggested and get back to you soon.
Best regards, Mingui > -----Original Message----- > From: Julien Meuric [mailto:[email protected]] > Sent: Saturday, April 15, 2017 1:55 AM > To: [email protected]; [email protected] > Cc: [email protected] > Subject: Routing Directorate QA Review of > draft-ietf-trill-multilevel-unique-nickname > > Hello, > > I have been selected as the Routing Directorate QA reviewer for this draft. > For > more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > At this stage, the intend of the following is not to discuss the WG's decision > about the I-D, but rather to help improving its content. > > Please note that, even though I have reviewed a few TRILL I-Ds in the past, I > do > not consider myself as being fluent in TRILL (yet?). > > _Summary_ > The document defines a protocol extension which looks both correctly > motivated and correctly scoped. However, the current wording of the behavior > requires some improvement to become clear enough to someone who has not > followed the associated discussions. > > _Comments_ > There are mainly 2 sections which deserve improvement. > > First, the 3rd paragraph in section 3.2 is requires that "global Data Labels > are > disabled". Without more background, the phrase could refer to: > - no global label is used/advertised, > - received global labels are ignored/dropped, > - received global labels are explicitly refused, > - global labels are not distinguished from local labels (as suggested by the > parenthesis). > >From the following sentence, I understand that a legacy RBridge may > benefit from global trees, however does it makes sense if that legacy RBridge > is > in a level 1 area and "MUST guarantee that global Data Labels are disabled"? > > Then, in section 4.3, I faced several (minor) issues. > > 1- The calculation of the length field seems incorrect. The formula looks > aligned > on the 1st figure on pages 9/10, depicting Nickname Blocks as 16-bit fields, > however the bottom of page 10 defines them as 32 bits. > As a result, the figure should extend the Nickname Block fields up to 2 > "lines" > and the length calculation would thus change to "2 + 4*K". > > 2- The definition of the set OK flag has puzzled me. Assuming it is meant to > enable a border RBridge to advertise the Nickname Blocks associated to its > attached Level 1 area, its definition is currently specified in a Level 1 > context, > and then scoped to both Levels 1 and 2. > However, the definition wording for Level 1 is not applicable to Level 2. This > could certainly be addressed either by a more generic definition (e.g. "Blocks > associated to its attached Level 1 area") or by a 2-step > definition: > - "advertisement in Level 1 means...", > - "advertisement in Level 2 means...". > > _Nits_ > Page 3: > - s/referred as the "unique nickname"/referred to as the "unique nickname"/ > - s/that are transitions between/that transition between/ > - s/RBrides/RBridges/ > > On figure 3.1, area boudaries looked odd, how about... > > Area X level 2 Area Y > +-----------------+ +---------------------+ +------------+ > | | | | | | > S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D > | 27 | | | | 44 | > | | | | | | > +-----------------+ +---------------------+ +------------+ > > On page 4: > - s/Let's say/Let us say/ > - s/let's say/let us say/ > > On page 5: > - s/only different is/only difference is/ > > On Figure 3.2, I assume that the order of the names on the first line does not > change anything, but I have been puzzled not to find RB2 as the list head. > Have > you considered putting it as the 1st one of the list? > > On page 9, the word "artificial" seems both odd and useless. > > In section 5, RFC 7176 is used as a fallback mechanism for incompatible > RBridges. What about its uses in other cases? Is it still allowed (though less > efficient) or precluded? A clarification would be useful (maybe in section > 4.3). > > On page 13, "TreeSel" is now RFC 7968. > > > Regards, > > Julien _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
