Re: [trill] Shepherd's report on draft-ietf-trill-ecn-support-04
Bob Briscoe <ietf@bobbriscoe.net> Sun, 04 February 2018 01:31 UTC
Return-Path: <ietf@bobbriscoe.net>
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 6001A1241F5 for <trill@ietfa.amsl.com>; Sat, 3 Feb 2018 17:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 BBhRJNHpQ2LC for <trill@ietfa.amsl.com>; Sat, 3 Feb 2018 17:31:45 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 BB261120726 for <trill@ietf.org>; Sat, 3 Feb 2018 17:31:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HT4Jch5hyH5ghyQddSa2kb8pjgGvmADOO5fWSYamb40=; b=K3hOOxoQFW9uqeAOheQo5Dv6r Mpz+3K+AC+mmZPmE5xisbDdZYhmNWg698c4fVSwvNJ3hWom519mAO5mpNOuAVMyvi3ePOb1C1F/m1 QFT2O4tEZBTI5v4abedH0ducD7VYqPK5UP1UyQtqj1HpiWsYsuEVQSgbWxrm6ucnyJx5e/+8Shh3T 3kqOxeioKt5QXfK52DcUi9WhpXtUV+Phe6PQVz8ibCPadO4g2+4JQbbd59M6dtNAsliFwH7HBRG2t E6kBQwwMiVY+Mh7a8sofOe4e2xgSD0jia2cyoh5TMmzavPsKFjU7gt/aLtGdYMdffx5AfvFyuDVIW 8t4eRmqqQ==;
Received: from 139.88.112.87.dyn.plus.net ([87.112.88.139]:33380 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <ietf@bobbriscoe.net>) id 1ei99h-000537-R6; Sun, 04 Feb 2018 01:31:42 +0000
To: Susan Hares <shares@ndzh.com>, 'Donald Eastlake' <d3e3e3@gmail.com>
Cc: trill@ietf.org
References: <00e901d39394$423c0930$c6b41b90$@ndzh.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <b7c521f9-8f5a-4dcd-9a0d-f2439495933a@bobbriscoe.net>
Date: Sun, 04 Feb 2018 01:31:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <00e901d39394$423c0930$c6b41b90$@ndzh.com>
Content-Type: multipart/alternative; boundary="------------17FB27713A7058332FF8DB19"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/adrUTwsJuoV61sp_Q-p8O76DaRg>
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: Sun, 04 Feb 2018 01:31:48 -0000
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 <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>]. SUGGESTED: ... which correspond to the recommended provisions in section 3 and sections 5.1-5.4 of [ECNencapGuide <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>]. 3.1. Ingress ECN Support CURRENT: ... it MUST follow the guidelines in [ECNencapGuide <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>] to add a Flags Word to the TRILL Header. SUGGESTED: ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>]. SUGGESTED: Drop is the intended behavior for such a packet, as required by Section 5.4 of [ECNencapGuide <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 <https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 > <https://tools.ietf.org/html/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 > <https://tools.ietf.org/html/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