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

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 03 July 2016 19:30 UTC

Return-Path: <jmh@joelhalpern.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 C5B2F12B00B; Sun, 3 Jul 2016 12:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level:
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 oJW2ZzB2pGOI; Sun, 3 Jul 2016 12:30:12 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523771288B8; Sun, 3 Jul 2016 12:30:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 226021C02D9; Sun, 3 Jul 2016 12:30:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1467574212; bh=iG5s4dSn91MeElQsxrp5PgpSLF0iVYn9VnJSBZXZ3R0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fH/ASKi6lk43trvnD2+IJghGBM8IRnpMISOn7+X+WMwPPAyGG4NlvcMIVepYsB1r5 rWoTzymTMvxx7xzZiORuv5QywBX7Cf+vHEGwWF3v91fL+2rGXn/txjbY0R3b8TFgNe pnVpQggCEj/B2E+/ukj7hXMmjW6Bzq+j1tO11YHU=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6F4DC1C0234; Sun, 3 Jul 2016 12:30:11 -0700 (PDT)
To: Donald Eastlake <d3e3e3@gmail.com>
References: <65c03289-d719-25ed-60fa-6f954edf2c5a@joelhalpern.com> <CAF4+nEGt04ZKfG9K1pjzEhb5d4dNEAs47xejnuaRWJz-FW+-SA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <85ada2d1-a6d3-973e-e5ee-ef441b34121b@joelhalpern.com>
Date: Sun, 03 Jul 2016 15:30:10 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAF4+nEGt04ZKfG9K1pjzEhb5d4dNEAs47xejnuaRWJz-FW+-SA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/j0AAwVcq--ETCOuB0G75Tjjg-H8>
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: Sun, 03 Jul 2016 19:30:14 -0000

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