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

Julien Meuric <julien.meuric@orange.com> Fri, 14 April 2017 17:55 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 111831294F0; Fri, 14 Apr 2017 10:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lw3TL9LZiFkx; Fri, 14 Apr 2017 10:55:17 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com []) by ietfa.amsl.com (Postfix) with ESMTP id 528B61294CF; Fri, 14 Apr 2017 10:55:14 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain []) by localhost (Postfix) with SMTP id 8FE2AE3009E; Fri, 14 Apr 2017 19:55:13 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown []) by p-mail2.rd.orange.com (Postfix) with ESMTP id 7A260E3009A; Fri, 14 Apr 2017 19:55:13 +0200 (CEST)
Received: from [] ( by FTRDCH01.rd.francetelecom.fr ( with Microsoft SMTP Server id 14.3.319.2; Fri, 14 Apr 2017 19:55:13 +0200
From: Julien Meuric <julien.meuric@orange.com>
To: <trill@ietf.org>, <draft-ietf-trill-multilevel-unique-nickname.all@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Organization: Orange
Message-ID: <ac8ad03e-b123-97f1-4ea3-b025307b7098@orange.com>
Date: Fri, 14 Apr 2017 19:55:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/b3JMsb2AryJM4SWfXmhalOlQ8hg>
Subject: [RTG-DIR] Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Apr 2017 17:55:19 -0000


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?).

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.

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
- "advertisement in Level 1 means...",
- "advertisement in Level 2 means...".

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
    +-----------------+ +---------------------+ +------------+
    |                 | |                     | |            |
    |     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.