Re: [trill] QA review of draft-ietf-trill-multi-topology-01

Donald Eastlake <> Tue, 31 May 2016 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E631A12D1CA; Tue, 31 May 2016 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8fWghjE_hzL4; Tue, 31 May 2016 11:11:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A919012D566; Tue, 31 May 2016 11:11:36 -0700 (PDT)
Received: by with SMTP id n63so150598217qkf.0; Tue, 31 May 2016 11:11:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eozcIgMSpbIyrIu3mxSujd1MZxNTQQGLqAfloKdl8qE=; b=IkFgNLSGSazL8xzJL80M6x6hvS/JkIPsUUkLsvVUzZbtTmBznAUrT22gmdGZEcXn1Z vrR5KtgI3CBfDEtQQe/guOMvQ78BJLbqtBY9gjEorjLoJda2GHcNzPnA6LGLH87RqOTm 4N/TZJqLdm3EHjS1iMeQwqc9a1LNPtBDvNxDDqiWVT2hQcCi7Jt8ojlX37xLJU51WOeO B+euRf2khrygBUUj1b5iuFdGV29N4ErVfy9tF+4lmLSVc2/Q81Z1EjKM8woJCEJut2Gm odZjBEWeCw+3w4yX2MQ9rMR5NYgsd/ypbHYrNZd2J0ym9/uhLgOcTIY9vunbwNkPQj1E bxgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eozcIgMSpbIyrIu3mxSujd1MZxNTQQGLqAfloKdl8qE=; b=OycBkoffTuEX1noa0J24hWXRviY5h4F5FQ8rGTI6rMXnsWIjvCndbjfeJHc6cfi644 IlGz9CBn9/yClZUQLE5iWDBhpDPzsH4k4OXlDe+c9gFCx7qLiDAy2Si298trfzVG0nwx 61Sm9evVndkdC1fOZU42bMVYvPvvsJVdQvMRWIMY0IyX7/cBpY6ZGOeqsOFQf0CGqaeE yOnDFnC23Ue/s4hvLEjAM0bQbD83To8b0jVSuhisCqcnjOr/8NtkfYjy7S1Ff9jsEWDF 01bwkw7lLvLWfQ+lKAAJ67x+p3vxO6ny6vbBPUJs2C+mPT9qryglkDRHp3hBeJMPMPZ7 gxuA==
X-Gm-Message-State: ALyK8tK8hn11RB6C5mpG0OsIEjA3HYtuTsRC/BvU3r5G6obXc2OkNsm82OPJZ/x1rElS7yR2i4bURJ+qb+AS9A==
X-Received: by with SMTP id t187mr32079894qkc.6.1464718295737; Tue, 31 May 2016 11:11:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 31 May 2016 11:11:21 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Tue, 31 May 2016 14:11:21 -0400
Message-ID: <>
To: Martin Vigoureux <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>,, "" <>
Subject: Re: [trill] QA review of draft-ietf-trill-multi-topology-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 May 2016 18:11:42 -0000

Hi Martin,

Thanks for your review. See response below.

On Mon, May 30, 2016 at 6:55 AM, Martin Vigoureux
<> wrote:
> Hi,
> I have been selected as the Routing Directorate QA reviewer for this draft.
> Document: draft-ietf-trill-multi-topology-01
> Reviewer: Martin Vigoureux
> Review Date: May 20, 2016
> Intended Status: Proposed Standard
> The draft is both quite well written and well structured such that I did not
> have to go back and forth in the doc.
> As a result also, I have only very few editorial comments and questions.


> Section 1
>    If routers in the network do not agree on the topology
>    classification of packets or links, persistent routing loops can
>    occur.
> It is not clear if that could happen in mt-trill or if mt-trill solves that.

Multi-topology TRILL doesn't specify what kind of traffic should be
classified as being in what topology. Indeed, the traffic classified
as being in topology T can be arbitrarily different in different parts
of the TRILL campus if there are disjoint instances of a topology T.
This classification needs to be decided and configuration by network
management. This is consistent with how IS-IS multi-topology is used
in other applications. So, yes, routing loops can be caused by
misconfiguring IS-IS mutli-topology is TRILL or IP.

> Section 1.1 goes beyond defining acronyms but specifies some pieces of
> technology:
>    By implication, an "FGL TRILL switch" does not support MT.
>    An MT TRILL switch MUST support FGL in the sense that it MUST be FGL
>    safe [RFC7172].
> Is this the right place to do this? By the way, this requirement is stated
> further down in the doc.

There is a similar sentence at the end of the entry for "VL". The idea
is that the capabilities of an "MT TRILL switch" are a superset of the
capabilities of an "FGL TRILL switch" which are in turn a superset of
the capabilities of a "VL TRILL switch". This is intended to simplify
things by having, at least to some extent, a linear sequence of added
capabilities rather than the cross product of the presence/absence of
each added capability. Sort of MT > FLG > VL. I don't see anything
wrong with having these statements here as well as further down in the

> Section 2.2
> s/and received/and receive/


> Section 2.4
>    Commonly, the topology of a TRILL Data packet is commonly
> One superfluous occurrence of "commonly"

OK. I think deleting the initial "Commonly, " would be a good
solution. So the sentence would start "The topology of a TRILL Data
packet is commonly ..."

> Section 2.4.1
> It would be better to write "2/3" as "2 and 3"


>    A TRILL switch advertising in a Hello on Port P support for topology
>    T but not advertising in those Hellos that it requires explicit
>    topology labeling is assumed to have the ability and configuration to
>    correctly classify TRILL Data packets into topology T by examination
>    of those TRILL Data packets and/or by using the fact that they are
>    arriving at port P.
> Does this mean that Value 1 is default behaviour?

The first paragraph of Section 2.4.1 makes it clear that the default
value of the two bit field in the Port Capabilities sub-TLV is zero
and this is also the value assumed if that sub-TLV is not present. I
can clarify the statement you quote above but it means exactly what it
says. "not advertising in those Hellos that it requires explicit
topology labeling" means it is not advertising a value of 2 or 3 in
the Explicit Topology capability field.

The sentence you quote is already effectively included in the entry
text for Explicit Topology capability field value 1. Probably the
sentence you quote should be deleted and the applicable portion of
should also merged into the text for Explicit Topology capability
field value 0. That seems like the best way to reduce confusion.

> Section 3.4.1
> s/are determine/are determined/


> Section 7
> s/some links was more/some links were more/


 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA