Re: [trill] Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname

["Zhangmingui (Martin)" <[e-mail]>]

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:[e-mail]]
> Sent: Saturday, April 15, 2017 1:55 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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