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

Donald Eastlake <d3e3e3@gmail.com> Mon, 04 July 2016 00:35 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C212D190; Sun, 3 Jul 2016 17:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pczoLo1YF2l; Sun, 3 Jul 2016 17:35:48 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B0312B062; Sun, 3 Jul 2016 17:35:48 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id f189so176686578oig.3; Sun, 03 Jul 2016 17:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.157.36.227 with SMTP id z90mr5882739ota.124.1467592547557; Sun, 03 Jul 2016 17:35:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Sun, 3 Jul 2016 17:35:33 -0700 (PDT)
In-Reply-To: <85ada2d1-a6d3-973e-e5ee-ef441b34121b@joelhalpern.com>
References: <65c03289-d719-25ed-60fa-6f954edf2c5a@joelhalpern.com> <CAF4+nEGt04ZKfG9K1pjzEhb5d4dNEAs47xejnuaRWJz-FW+-SA@mail.gmail.com> <85ada2d1-a6d3-973e-e5ee-ef441b34121b@joelhalpern.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 3 Jul 2016 20:35:33 -0400
Message-ID: <CAF4+nEHi5DPmB2kd0jH9ET6JxBURDt_E-55Vsvpcov91ExOPug@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/llz0ISXPG3v8mBMypaXqejP0pFg>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "trill-chairs@tools.ietf.org" <trill-chairs@tools.ietf.org>, draft-ietf-trill-rfc6439bis@ietf.org, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Routing directorate QA review of draft-ietf-trill-rfc6439bis
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=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.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Sun, Jul 3, 2016 at 3:30 PM, Joel M. Halpern <jmh@joelhalpern.com>; 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 <jmh@joelhalpern.com>;
>> 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
>>  d3e3e3@gmail.com
>>
>>> Yours,
>>> Joel M. Halpern