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, 03 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
- 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