Early Review of draft-ietf-trill-multilevel-unique-nickname-01
review-ietf-trill-multilevel-unique-nickname-01-rtgdir-early-meuric-2017-04-16-00

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