Re: [trill] Shepherd's report on draft-ietf-trill-ecn-support-04
Donald Eastlake <d3e3e3@gmail.com> Mon, 05 February 2018 04:59 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 5D656126CD6 for <trill@ietfa.amsl.com>; Sun, 4 Feb 2018 20:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 m9eIvp4ccImH for <trill@ietfa.amsl.com>; Sun, 4 Feb 2018 20:59:32 -0800 (PST)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 73E131205D3 for <trill@ietf.org>; Sun, 4 Feb 2018 20:59:32 -0800 (PST)
Received: by mail-ot0-x234.google.com with SMTP id f18so1743768otf.6 for <trill@ietf.org>; Sun, 04 Feb 2018 20:59:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ePQ8b+IcjFzz7OBGjRFb6Bj5cmSJHxOd0TJRfEcG1CE=; b=dU3o5G/MLuiMti48OH9Im5VRNbGHnT1iwXh1DKE1+8tx+XSMxkAep3/jx4Y4fQCMxK 688zK1o35bEuF3K0N1+Dqw9Ttv8tiXKnF9wzelLR/6fNjY4wANL4+RedLCTaGhngpoCw Yw+Iro8Z4e4UFawyS+sfC3mChlrcJ2GTN7eFOv2ggCOWhvhlNfaJpp7jrJDdpjlgVU5W uHwzQ+fI12JKPjYp41GYJfV/owbeHQgGzhGlvUiUEocj3NA57MIhnL1mdaPD17S6xrdt IPEZq5U2kk0WOIXsahL/2eDTeNzf65C98ravzVwlbFLT8CfHyva4ZpsjLicL+xdkcbjz xzgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ePQ8b+IcjFzz7OBGjRFb6Bj5cmSJHxOd0TJRfEcG1CE=; b=VrxKZOtaE18ehA5m5WroAJiDG0jzGvrj7uoGXVaZLGFGUZgvx8aFQB7bTqU61ZDAIo lakUrEDSY+2idYA3jURYIQHMVFffMFTt8xyMmrtoI8mxA8XM1a5kc2qFFqNrpk9L6X4B hSMDClT7OffHhxeg71OSTKmoUnXQqrLwb3mSyj1xri+OwoVYTRWaVhV52cWJ1TSKPbfJ lQRKQpszHSN73FllnXFHnM5IyAm4oqBF/C8jYtuBC8CUbC04xnoo4hrlEsAEn3oI+45u s6ZCcWz7ExCQzy0wqXv75AEN9gcaFZ9I1LTmx+ZgXYJEil5PV8hMprsmo8E6Xi6MmviU mdCg==
X-Gm-Message-State: AKwxytfu7GYk21NQPnAwngM2pYP6ht4YA3YJS6vYMiIgJrcOI66mZq+3 yrpPMS1AQ5U/FJT0LXgBrhR94JiE2PibWoPSTCs=
X-Google-Smtp-Source: AH8x227W34AX9e3oPOxu367GdJzwtM3ROn9UpRjlONU0aeNE0oucuN0yrO6gaD54vGi0kd/oSXWMwex9R61adB+1Ktg=
X-Received: by 10.157.19.46 with SMTP id f43mr35065565ote.139.1517806771478; Sun, 04 Feb 2018 20:59:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Sun, 4 Feb 2018 20:59:16 -0800 (PST)
In-Reply-To: <b7c521f9-8f5a-4dcd-9a0d-f2439495933a@bobbriscoe.net>
References: <00e901d39394$423c0930$c6b41b90$@ndzh.com> <b7c521f9-8f5a-4dcd-9a0d-f2439495933a@bobbriscoe.net>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 04 Feb 2018 23:59:16 -0500
Message-ID: <CAF4+nEH=zKg-cA9eDDR2NW=v6L9gS+ogWH5rQXVpj8eO2Hzxxg@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Susan Hares <shares@ndzh.com>, trill@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/aQ63PmJdunq50iKhsY6ykgnD6z4>
Subject: Re: [trill] Shepherd's report on draft-ietf-trill-ecn-support-04
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Feb 2018 04:59:34 -0000
Hi Bob, All your changes look good to me. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Feb 3, 2018 at 8:31 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote: > Sue, > > Thanks for the editorial suggestions. > Donald, I'm happy with Sue's specific suggestions if you are. > > Responses inline... > > On 22/01/18 15:18, Susan Hares wrote: > > As part of the shepherd’s duties, I’ve review > draft-ietf-trill-ecn-support-04.txt to determine if it is ready for > publication. > > > > Status: Ready with editorial nits > > > > General comment: I’m thrilled to see an RBridge specification enacting aids > for advanced congestion control mechanisms. > > What I’ve checked: normative references including > draft-ietf-twvwg-enc-encap-guidelines-01/txt > > BTW, it's currently -09, not -01. > > I suggest the following changes to each occurrence of a citation of > [ECNencapGuide]: > > 1. Introduction > <No change to both citations, which are to the whole of [ECNencapGuide] in > general> > > 3. ECN Support > > CURRENT: > > ... which correspond to the recommended provisions of > [ECNencapGuide]. > > > SUGGESTED: > > ... which correspond to the recommended provisions in section 3 and > sections 5.1-5.4 of > [ECNencapGuide]. > > > 3.1. Ingress ECN Support > > CURRENT: > > ... it MUST follow the guidelines in [ECNencapGuide] > to add a Flags Word to the TRILL Header. > > > SUGGESTED: > > ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide] > to add a Flags Word to the TRILL Header. > > > 3.3 Egress ECN Support > > CURRENT: > > Drop is the intended behavior for such a packet, as required by > [ECNencapGuide]. > > > SUGGESTED: > > Drop is the intended behavior for such a packet, as required by Section > 5.4 of > [ECNencapGuide]. > > > CURRENT: > > o When decapsulating a non-IP protocol frame with a means of > indicating ECN that is understood by the RBridge, it MUST follow > the guideines in [ECNencapGuide] when setting the ECN information > in the decapsulated native frame. > > > SUGGESTED: > > o When decapsulating a non-IP protocol frame with a means of > indicating ECN that is understood by the RBridge, it MUST follow > the guideines in Section 5.4 of [ECNencapGuide] when setting the ECN > information > in the decapsulated native frame. > > > > > > Editorial nits are below. You can adopt or ignore the editorial nits. > > > > Sue Hares > > =========== > > > > Editorial nits: > > > > General – it may be helpful to specify section in the [ECNencapGuide] – > document, and RFC7567. While the way you specify it is correct, it may help > the reader to narrow down the scope within the document. > > > > #1 > > Explicit congestion notification (ECN [RFC3168]) allows a forwarding > > element, such as a router, to notify downstream devices, including > > the destination, of the onset of congestion without having to drop > > packets. > > > > The multiple commons in this sentence do not lend to easy reading of the > initial sentence. > > One alternative is: > > > > Explicit congestion notification (ECN [RFC3168]) allows a forwarding > > Element (such as a router) to notify downstream devices, including > > the destination, of the onset of congestion without having to drop > > packets. > > > > However you may wish to revise the sentence in an alternative way. > > > > > > #2 – Section 2. Paragraph 2. Sentences 4 > > Old/Extesnion Flags Word./ > > New/Extension Flags Word./ > > > > > > #3 – Section 3.3 is dense and thoughtful text. I am not sure you can > improve it, but it too me several reads to make sure I understood it > correctly. > > > > I think it might help if we created two subsections within 3.3 for: > 3.3.1: "Non-ECN Egress RBridge" the first para > 3.3.2: "ECN Egress RBridge" for the rest of the section > > Also, it might make it clearer if the two bullets were explicitly flagged as > mutually exclusive alternatives: > > CURRENT: > > If an RBridge supports ECN, the egress behavior is as follows: > > SUGGESTED: > > If an RBridge supports ECN, for the two cases of an IP and a non-IP inner > packet, > the egress behavior is as follows: > > > Then, instead of the two bullet symbols, perhaps use hanging indented > headers: > > Decapsulating an inner IP packet: The RBridge sets the ECN > ... > Decapsulating a non-IP protocol frame: If the frame has a means of > indicating ECN that is understood by the RBridge, the RBridge MUST > follow > ... > > > > Other suggested edits to make the going easier: > > CURRENT: > > In the case where the TRILL 3-bit ECN codepoint indicates > congestion experienced (CE) but the encapsulated native IP frame > indicates a not ECN-capable transport (Not-ECT), the RBridge MUST > drop the packet. > > > SUGGESTED: > > In the case where the TRILL 3-bit ECN codepoint indicates > congestion experienced (CE) but the encapsulated native IP frame > indicates a not ECN-capable transport (Not-ECT), it can be seen that > the RBridge MUST > drop the packet. > > RATIONALE: > To reassure the reader that this req't is already described in the table; it > is not an additional req't. > > HTH > > > > Bob > > > > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/
- [trill] Shepherd's report on draft-ietf-trill-ecn… Susan Hares
- Re: [trill] Shepherd's report on draft-ietf-trill… Bob Briscoe
- Re: [trill] Shepherd's report on draft-ietf-trill… Donald Eastlake