Re: [trill] Routing directorate QA review of draft-ietf-trill-rfc6439bis

Donald Eastlake <> Sun, 03 July 2016 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C223512B034; Sun, 3 Jul 2016 10:53:55 -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 lY8091NjvHUw; Sun, 3 Jul 2016 10:53:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E48FD12B01D; Sun, 3 Jul 2016 10:53:53 -0700 (PDT)
Received: by with SMTP id s66so170460405oif.1; Sun, 03 Jul 2016 10:53:53 -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=SYXS8hhVSLXYW5THhPuO56sL3DF4WNVMosQUBF/Bf7E=; b=xLJNUCrqvdeJ9dGHrxiOXLcMVRaM5ZD7tM1lKLyK94s3oX6WsddGH3m5ziYc7xJjUB q7qqU1LSgzHoDYCnz3PhWDalR1QVqI36hdczjOgq6l/ezzjOUniqfhuOTZotQwd73UfJ YwJN1D2ejcBE6+Fr0S44YdOTUU/0gz7DduhIbw5xKxGO+0XH4MKAbCe5YIGonKjaQLqq 0MTy61IZnrzY4crLQF2p6XQ1wrIEvU3wsUrrKf2rBbDCKLuvJWg8RifksXIIQ7l4Lp6U 4h0FTGXDXlKv/4jJ2lyxLb3dfPPkHx9bZGqzmImGan3E7iYUc2oaznWhDwdZUQn4SOaL R7qw==
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=SYXS8hhVSLXYW5THhPuO56sL3DF4WNVMosQUBF/Bf7E=; b=NSD6Qiio86bjLEv9gZwXDUfeIL0tcxabY3teL/gafJeEgVTWuyxBRsx48ISKChwubg L909Qc3yHhSslQ9sP6APZ/eORAZws/LVM+2HU2wqrsDv0MBOaZa1e99a1WwceGWsQp/C 16NVWlQ5pvstTqoFdi9Zttmfh1wYl17Lgrka4Td0JI6+lZNUUCR7ln0Pt9ixozzbV9ns C1QIQyA+DUhlw/ZqSV/Iwrp0DmwPmFByGlwngDet2Ie/jQB61gKWLykGbdODx8IDQ/3t 2xth6akfsWX3xQXOJxOATflYxtTN4ORSiQ+bhA88p4UrU9nULViYoyn18hOff1pzp4z6 WwZg==
X-Gm-Message-State: ALyK8tLqaDNXZhWvMIU46HQaIjQgZXm8mzQyALdORXiuaU8pgI/8DgeRMeQH+MQSbovfNyXJOp85IVWHYR99vg==
X-Received: by with SMTP id h94mr2566330otb.170.1467568433036; Sun, 03 Jul 2016 10:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Jul 2016 10:53:38 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Sun, 3 Jul 2016 13:53:38 -0400
Message-ID: <>
To: "Joel M. Halpern" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, "" <>,, "" <>
Subject: Re: [trill] Routing directorate QA review of draft-ietf-trill-rfc6439bis
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: Sun, 03 Jul 2016 17:53:56 -0000

Hi Joel,

Thanks for your comments.

Because this draft happens to be close to expiring and we are coming
up on the refractory period before the Berlin meeting, I'm going to do
my best at editing it based on your comments and upload a revision.
But if that does not resolve your comments, further changes can be

See below.

On Sun, Jun 26, 2016 at 8:58 PM, Joel M. Halpern <> wrote:
> This is a QA review, intended to provide an additional perspective,
> requested by the TRILL chairs and Routing ADs.
> The reviewer understands that the WG last call has completed, and hopes that
> this review will prove helpful to the working group.
> [For clarity, the above is written before performing the review.]
> This document is ready for publication as a Proposed Standard RFC.
> Major: N/A
> Minor: N/A
> Nits:
>     Section 2.2 base has two bullet items.  the first appears to be a subset
> of the second.  Is this deliberate?

You are correct. I guess as an author I thought of the second point as
being more restricted than the words actually are. I was thinking it
actually said something like "When it observes a change in DRB on the
link from one RBridge other than itself to another RBridge other than
itself." However, it seems like it would be clearer to re-write that
small section of text.

>     The counter-example at the end of the second paragraph of section 2.4
> seems to be missing some limitation that would explain it.  (It is possible
> this is more obvious to a reader who is more conversant with TRILL, but
> there does seem to be something missing.)

Maybe the wording isn't very clear. Let me describe the counter
example somewhat more verbosely in different words.
     Say that all the end stations in a TRILL campus that are in
VLAN-x are attached to RBridge-1.  That means that they are on links
that is attached to RBridge-1 and there might be one or more other
RBridges attached to those links. (Note that in TRILL, a link can be a
bridged LAN.) On each such link, there will be a Designated RBridge
election to chose the RBridge that is in charge of end station traffic
on that link, either ingressing/egress such traffic itself or
assigning it to one or more other RBridges on that link by VLAN.
     Assume that RBridge-1 is overloaded. Thus RBridge-1 will
typically do a poor job of forwarding traffic, because it cannot hold
the complete topology. Normally, you would not want RBridge-1 handling
end station traffic. If RBridge-1 wins the DRB election on a link, it
should assign the handling that traffic to other non-overloaded
RBridges on its links, if such RBridges are available, and if some
other RBridge on a link wins the DRB election, it should not assign
the handling of such traffic to RBridge-1.
     However, in the case of VLAN-x traffic, all the end stations in
VLAN-x have local connectivity to RBridge-1. The inability of
RBridge-1 to do a good job forwarding traffic is immaterial to traffic
in VLAN-x because it will never have to forward it because all end
stations in VLAN-x are local. Thus, even through RBridge-1 is in
overload, it SHOULD be assigned the handling of end station traffic
for VLAN-x.

I'll try to clarify the wording in the draft.

> Editorial:
>     In section 10.4 defining the FGL-VLAN Mapping Bitmap APPsub-TLV, the
> diagram calls the fifth field "Starting FGL".  The text below that refers to
> it the field simply as "FGL".  I believe the text should also name it
> "Starting FGL".


> Side note: I really appreciate the thorough additional explanations as to
> the reasons various actions are safe or unsafe.  Thank you.

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

> Yours,
> Joel M. Halpern