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

Donald Eastlake <> Mon, 04 July 2016 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D7C212D190; Sun, 3 Jul 2016 17:35:50 -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 5pczoLo1YF2l; Sun, 3 Jul 2016 17:35:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63B0312B062; Sun, 3 Jul 2016 17:35:48 -0700 (PDT)
Received: by with SMTP id f189so176686578oig.3; Sun, 03 Jul 2016 17:35:48 -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=dZ6FeHosqPORl0mZWDN7J3SPFiDBP8T3gGVss1eOZ4U=; b=cZKjK4RWnIckGZnZajpNueyw6FMsqS9MkJU+/wak6qIbCju6WLnCcnBHXKDpWPeIux OzMfYQFQKBSxaGUxGjIB9I0attWXZhcVIwmUh2xfC2Uq/pYZ5eGhnFzhHIXVqu51O3cA 2xP3BlCfui+2Dmm5+wiZwwwoEQy8BRKWADx/zqK3ZeVgCbGmt4f9QcwEbi7D2yQQQiit p9N8or8LTgMZfaYuKbtDzPbYSjtGvuHB/A7q6PRBsZjIemNl/CId2if7CPzSsy/X1Dyp tg+MW+YB0C1/bhQw31cmKbVChQfqS9TT/QevE3zBoxT691zwn3lz2DeO0V7Ouh5XSrl5 sjRg==
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=dZ6FeHosqPORl0mZWDN7J3SPFiDBP8T3gGVss1eOZ4U=; b=b4v+MfmnhHmJKtIvaXqpS/cBpTNfgg8aqJxAZKbGhyzuMf5bA5xb8N8QQrN2PdddOS fZZPcHxdctuTjqK2Q1szYdAVM/gDA1U7jwfLLL23Ht1XnZe/x8We0pJhxMNNlQleLAv4 fMCyLIEvSkp3FSM3WvW9vlLn+lPv3FoEpPjUT4OHKRDqNXban0zuBjc7kY9S0B/B8GAy oMSsc2DlsK8RoabVpHoGfmB98h3zHB043bBp10HkDFAaHeGu0muHSaiGMHAcxRkMMhYV jrfZGN7p07wNJ+twhCy6/WFvbm+JS6lWi5GCjcDIda1YaeYnUWar2dwgUByu77F0yYzW RXww==
X-Gm-Message-State: ALyK8tLVrhOl0GEdG+rP5G5KVMLcmQpN8lrJGx9UTOwDwvCJOi9bMaHLVHdGEZPMUI3LQAsHwmML+PAiKLT2eA==
X-Received: by with SMTP id z90mr5882739ota.124.1467592547557; Sun, 03 Jul 2016 17:35:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Jul 2016 17:35:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Donald Eastlake <>
Date: Sun, 3 Jul 2016 20:35:33 -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: Mon, 04 Jul 2016 00:35:50 -0000

Hi Joel,

A -02 version has been posted intended to resolve your comments.

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

On Sun, Jul 3, 2016 at 3:30 PM, Joel M. Halpern <> wrote:
> Thanks Donald.  Looks good to me.
> Yours,
> Joel
> On 7/3/16 1:53 PM, Donald Eastlake wrote:
>> 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
>> made.
>> 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".
>> OK.
>>> 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
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>> Yours,
>>> Joel M. Halpern