Re: [trill] AD review of draft-ietf-trill-cmt-06

Donald Eastlake <> Fri, 31 July 2015 17:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24BD31B2E96; Fri, 31 Jul 2015 10:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TFEAIb4gmCnu; Fri, 31 Jul 2015 10:01:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A19711A8A55; Fri, 31 Jul 2015 10:01:50 -0700 (PDT)
Received: by obre1 with SMTP id e1so58313347obr.1; Fri, 31 Jul 2015 10:01:50 -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:content-type; bh=WtQOiISxFnERr+ffiu/OHALl+mx1M3Wv6dS5mWyCv1Q=; b=IC6BBWPtmfSN+iO9jnpziY0XRaFBhsvIGeo2vE3TBKxNcPE2rMqfkqlzYSAGXzgr78 HLLnE2ysfMn07eC17mncuElAhwZ/imM6A0HlDyw8U2zpiOZ43DLx3jOQZFP0xCWGuezn zNjzsFMMSLNqhJU1VebRQqVOajNJ534Fe/XBrDRwG9//G7QgUbFYk4+S17y9rjh4u2i4 muvXxhIslAhc9jnopaDhgdjDngkaJuTb2pGosLr6hDiHuaL9zSiSAW/NbOldpOM1y07I IXqTxt5Elffm8XeogaLlLoFM29oIEcC2ZIZliHrdKEF8FGuspA43qbBqYhd+x6zhMNU9 vGag==
X-Received: by with SMTP id dp3mr4468008oeb.47.1438362110126; Fri, 31 Jul 2015 10:01:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 31 Jul 2015 10:01:35 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Fri, 31 Jul 2015 13:01:35 -0400
Message-ID: <>
To: Alia Atlas <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Tissa Senevirathne <>,, "" <>
Subject: Re: [trill] AD review of draft-ietf-trill-cmt-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2015 17:01:52 -0000

Hi Alia,

On Fri, Jul 31, 2015 at 11:22 AM, Alia Atlas <> wrote:
> First, I'd like to thank Tissa, Janardhanan, and Jon, the authors of this
> draft, for their hard work and clear writing that makes this very easy to
> read and understand.

Note: Tissa is not longer with Cisco. I've added an email for him above.

> As is customary, I have done my AD review of draft-ietf-trill-cmt-06 before
> requesting IETF Last Call.  I do have a few comments that I hope can be
> addressed rapidly.
> I would really like to get IETF Last Call started on this draft (and the
> other two associated trill drafts that make sense to progress at the same
> time), but I do feel like some clarification or discussion is really needed.
> Today is the last day I can request IETF Last Call and still have the draft
> be on the August 20 telechat.  Otherwise, it will have to wait another two
> weeks.  I realize that these drafts have been waiting for a long time (and
> apologize for my part in the delay), but I'd like to get them moving rapidly
> now.

I'm sure the authors will correct me if I am wrong but here is my understanding:

> Major Issues:
> 1) In Sec 5.3, it says "If an RBridge RB1 advertises an Affinity sub-TLV
> with an AFFINITY RECORD that's ask for nickname RBn to be its child in
> any tree and RB1 is not adjacent to a real or virtual RBridge RBn,
> that AFFINITY RECORD is in conflict with the campus topology and MUST
> be ignored."  How does an RBridge determine the connectivity of a
> virtual RBridge RBn?  I can see that a Designated RBridge announces
> the pseudo-nickname for the vDRB to the other RBridges in the LAALPs
> (as described in draft-ietf-trill-pseudonode-nickname) but I don't see
> any specific way that the connectivity of a virtual RBridge is
> described and known by the other RBridges.  What am I missing?

Well, a virtual RBridge represents an edge group of RBridges that all
have ports to links that are part of an active-active group of links.
The RBridges in the edge group advertise in IS-IS an ID for that edge
group which is unique in that TRILL network (campus) -- usually pretty
easy as they just use the MC-LAG (or DRNI) ID. So all the members of
the edge group can see each other in the link state and the highest
priority member obtains and advertises in IS-IS the nickname for the
virtual RBridge representing that group. All RBRidge in the edge group
are assumed to be "connected" to that virtual RBridge.

> Minor Issues:
> 2) In Sec 5.1, it talks about the tree number.  Is how the tree number
> derived described elsewhere?  Is this something that each RBridge can
> do independently?  Could you add a reference?

Sure. Tree numbering was originally specified in the TRILL base
protocol document RFC 6235 and each RBridge independently determines
the trees and their number; however, this numbering was changed by
Section 3.4 of RFC 7180 which updates 6325. RFC 7180 is being replaced
by draft-ietf-trill-rfc7180bis and retains, still in Section 3.4, that
change. So, to avoid delays, probably a reference to Section 3.4 of
RFC 7180 (already a normative reference for this trill-cmt draft)
would be best.

> 3) In Sec 5.1, could you clarify which RBridges are doing the
> Distribution Tree provisioning?  I'm sure it's my lack of deep
> familiarity, but until I got to Sec 5.2, it wasn't at all clear to me.

I'm not sure that "Distribution Tree Provisioning" is the best name
for that section. In TRILL, every RBridge in the campus independently
computes the same set of distribution trees for the campus and each
tree reaches every RBridge (right now, this will change with
multi-topology, etc.). This section is about the assignment of edge
group RBridges to trees. They all know about all the trees due to how
tree calculation works in TRILL and they all know about all the
members of the edge group. So each member of the edge group does the
calculations described in 5.1 and they will all come up with the same
assignment of edge group RBridges to trees.

> 4) In Sec 5.6, it says "Timer T_j SHOULD be at least < T_i/2" Do you mean
> that timer T_j should be no more than T_i/2 or that timer T_j should be no
> less than T_i/2.  The "<" makes this unclear to me because the "at least"
> contradicts it; is it T_j < T_i/2 or T_i/2 < T_j.

I am less familiar with that provision so I'm not sure what the
correct interpretation is. It should probably be clarified.

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

> Thanks again,
> Alia