Subject: [RTG-DIR] Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname

From: Julien Meuric <[email-masked]>
Date: Fri, 14 Apr 2017 19:55:12 +0200

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

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Mon, 17 Apr 2017 06:49:09 +0000

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-masked]]
> Sent: Saturday, April 15, 2017 1:55 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> 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_
> 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_
> First, the 3rd paragraph in section 3.2 is requires that "global Data Labels are
> disabled". Without more background, the phrase could refer to:
> - global labels are not distinguished from local labels (as suggested by the
> parenthesis).
> 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"?
> 
> 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:
> 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?
> 
> 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).
>