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
- Re: [trill] Routing directorate QA review of draf… Donald Eastlake
- Re: [trill] Routing directorate QA review of draf… Joel M. Halpern
- Re: [trill] Routing directorate QA review of draf… Donald Eastlake
- [trill] Routing directorate QA review of draft-ie… Joel M. Halpern