[tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12
"Black, David" <David.Black@dell.com> Thu, 09 May 2019 00:11 UTC
Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1E12019B for <tsvwg@ietfa.amsl.com>; Wed, 8 May 2019 17:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=ybuGYOyG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=On+wGbCz
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 zECrn6fX-tk5 for <tsvwg@ietfa.amsl.com>; Wed, 8 May 2019 17:11:03 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 4544412014E for <tsvwg@ietf.org>; Wed, 8 May 2019 17:11:03 -0700 (PDT)
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x48Nxg1k001931 for <tsvwg@ietf.org>; Wed, 8 May 2019 20:11:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=p3KqtqXL+8S8UKdBeRvDxwOcd5vS9XJPpDjQutmcNy8=; b=ybuGYOyGG4sJ5eS/LFgxw7L/nyahEZODdwmBa09UUTwF9BHBkTDVslv/KBapLQMKHpqe x4Ql1TLETiDlPo3hLft02MqwwQbTevPk0m/8PdHsuFo4KdMn+GZQMVyPUd0f7NBOjXAl j/Zk+i/MJbN7XyVrYI0+MMCY+Ilgq9i2Fbn2Of9b+zyT4kMVEMPrv9AlvqE1ej/tFFA6 9qSsZ2obXWwCi9RE/RHMhl8S7HomfSDBPOp4DUGNyf7YuW8LiNMYCjC22luxzP7c/ofi EA/UuSv5BAbNZIdI8k02Q2LM62whDwdtYNCH9XsyLeJVMbeWH4w88zSg6jy2pmpQLxE1 3Q==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 2sbtcgkcru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Wed, 08 May 2019 20:11:01 -0400
Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4903ef2059955 for <tsvwg@ietf.org>; Wed, 8 May 2019 20:11:01 -0400
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0a-00154901.pphosted.com with ESMTP id 2sc6xqhmdt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Wed, 08 May 2019 20:11:00 -0400
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490AwUE032147 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tsvwg@ietf.org>; Wed, 8 May 2019 20:10:59 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x490AwUE032147
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1557360659; bh=c/JXP6RcNHoSQRKM+R71de55cbA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=On+wGbCzzdtgWbA8YULioa4kHpfU1rsM0IkyaHX3LMGbacZ+Yvf9Hk9lMmCz4QnqA 06H2ptF/k8ZZGEGpqoEw7H1neJzSpEYxqRGISiVErDX06DnbsqtisbSmfc+K2s4/gq gu1kTCcfj92HiSuWdEE/ycXwo18qaO7DJAu710yA=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x490AwUE032147
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Wed, 8 May 2019 20:10:36 -0400
Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x490AaKt009158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Wed, 8 May 2019 20:10:37 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0439.000; Wed, 8 May 2019 20:10:36 -0400
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12
Thread-Index: AdUF+PJKfYny0XdBSEe2JZXBy1PR5A==
Date: Thu, 09 May 2019 00:10:35 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363055BB8D@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.130]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363055BB8DMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-08_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905080143
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905080143
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hBxUCkAdN-ROPhG7G80Alo8iZSU>
Subject: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 00:11:09 -0000
First of all, this is a well-written and comprehensive draft on ECN encapsulation design guidelines. I found no major issues, and all of the minor issues are truly minor - some border on editorial, and all can be dealt with via relatively minor edits. --- Minor --- [A] Need an explicit statement of exactly what the update to RFC 3819 is, preferably in a section whose name uses "RFC 3819" and appears in the table of contents. Do this before some AD tells you to ;-). This is also the only thing that idnits found that needs attention. [B] 1. Introduction, first paragraph, last sentence The phrase "egress at any layer" is too general, hence incorrect (e.g., layer 7 was not intended to be included) - "lower layer" needs to be used for clarity. OLD If an egress at any layer is not ECN-aware, or if the ultimate receiver or sender is not ECN-aware, congestion needs to be indicated by dropping a packet, not marking it. NEW If a lower layer header that may contain ECN congestion indications is removed by an egress that is not ECN-aware, or if the ultimate receiver or sender is not ECN-aware, then lower layer congestion needs to be indicated by dropping a packet, not marking it. END [C] 1.1 Scope Second paragraph and the two-bullet list imply that RFC 4774 states that use of ECT(1) to signal alternative ECN semantics is a best current practice. That's not correct, as RFC 4774 covers only the first bullet on use of DSCP, not the second bullet on use of ECT(1), as that second bullet is based solely on RFC 8311. Some rewriting is in order to disconnect the second bullet from RFC 4774. Based on this, all other places where RFC 4774 is mentioned or cited should be checked to determine whether RFC 8311 also ought to be mentioned or cited. [D] Page 5, first complete paragraph Alternative semantics for the ECN field can be defined to depend on the traffic class indicated by the DSCP. Therefore correct propagation of congestion signals could depend on correct propagation of the DSCP between the layers. This also depends on correct propagation across diffserv boundaries - that and the potential damage wrought by bleaching DSCPs to zero at such boundaries both deserve mention here. [E] 1.1 Scope, end of section In the feed-backward mode, propagation of congestion signals for multicast and anycast packets is out-of-scope (because it would be so complicated that it is hoped no-one would attempt such an abomination). Much as I may agree with it :-), the parenthetical remark is inappropriate for an archival RFC, and hence needs to be removed. [F] 2. Terminology ECN-PDU: A PDU that is part of a feedback loop within which all the nodes that need to propagate explicit congestion notifications back to the Load Regulator are ECN-capable. That first sentence is too broad as it includes both the forward and reverse directions of the feedback loop, whereas only the forward direction is intended (FWIW, the definition of PDU does not suffice to narrow this to the forward direction only). For example, a TCP packet with the ECE flag set in the TCP header and Not-ECT in the ECN field in the IP header would be an ECN-PDU under this definition, which is not what was intended. The immediately following definition of Not-ECN-PDU has the same problem. The narrowing concept that needs to be added is that if the PDU carries a congestion indication, then that congestion indication participates in such a feedback loop, and even that is subtle when there are multiple possible congestion indication locations. An example of the subtlety is that the same PDU may be an ECN-PDU in feed-up-and-forward mode because the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for feed-forward-and-up mode because the L2 decapsulator ignores and discards L2 congestion indications. [G] 2. Terminology Congestion Baseline: The location of the function on the path that initialised the values of all congestion notification fields in a sequence of packets, before any are set to the congestion experienced (CE) codepoint if they experience congestion further downstream. Typically the original data source at layer-4. That's counter-intuitive - a baseline is a level, not a location. I've tagged this as a minor issue as opposed to editorial because it causes severe confusion in the only place that this term is used, namely item 3 in Section 4.3. That item 3 is about a Monitoring Baseline which is a level not a location. The Congestion Baseline term should be removed, and item 3 in Section 4.3 revised accordingly. The term "Congestion Baseline" is used twice there, but only the latter of those two uses needs to be retained and expanded after deletion of this definition. [H] 3. Modes of Operation Feed-Up-and-Forward: A lower layer switch feeds-up congestion notification directly into the ECN field in the higher layer (e.g. IP) header, irrespective of whether the node is at the egress of a subnet. Remove "the ECN field in" as that's too restrictive, even though that's a common case, and move it into the example - "(e.g., ECN field in the IP header)" where "header" moved inside the parentheses. [I] 3.3. Feed-Backward Mode Please make it clear that the critique of the ATM ABR relative rate control mechanism also applies to Ethernet QCN, as that's a more current example. This should be connected to the QCN discussion at the end of Section 4.2. [J] 4.3 Encapsulation Guidelines Resolving minor issue [G] requires some edits to item 3 in this section: - Remove "(the Congestion Baseline)" from the third paragraph. - Rewrite start of fourth paragraph: OLD Most information can be extracted if the Congestion Baseline is standardised at the node that is regulating the load (the Load Regulator--typically the data source). NEW More information can be extracted if the protocol specification requires that congestion fields be initialized to indicate no congestion only by the node that is regulating the load (the Load Regulator--typically the data source). END [K] 12.2 Informative References Please check the references to 802.1Qah and 802.1Qau with IEEE. The correct references to use now may be the latest version of 802.1Q with specific functionality and/or clauses identified. --- Editorial/Nits --- Abstract, last sentence Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. between new -> among IP layer and 1. Introduction, first paragraph Suggest removing use of the word "buffer" - "lower layer" suffices in all of the places where this word is used in this paragraph. 1. Introduction, second paragraph The purpose of this document is to guide the addition of congestion notification to any subnet technology or tunnelling protocol, so that lower layer equipment can signal congestion explicitly and it will propagate consistently into encapsulated (higher layer) headers, otherwise the signals will not reach their ultimate destination. Suggest: "equipment" -> "functionality" Page 5, first full paragraph: If a particular protocol design chooses to contradict a 'SHOULD (NOT)' given in the advice below, it MUST include a sound justification. chooses to contradict -> chooses not to follow 1.1. Scope, first paragraph This document only concerns wire protocol processing of explicit notification of congestion. Remove "wire" Section 3.1, second paragraph In these cases, ECN may best be supported by standardising explicit notification of congestion into the lower layer protocol that carries the data forwards. It will then also be necessary to define how the egress of the lower layer subnet propagates this explicit signal into the forwarded upper layer (IP) header. It can then continue forwards until it finally reaches the destination transport (at L4). Then typically the destination will feed this congestion notification back to the source transport using an end-to-end protocol (e.g. TCP). This is the arrangement that has already been used to add ECN to IP- in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. The referents of "It" at the start of the second and third sentences are unclear and different. Suggested rephrasings: It will then also be necessary to define -> This necessitates also specifying It can then continue -> This signal continues Section 3.1, first paragraph after Figure 1 Cite one or more of the 3GPP references for GTP tunnels, as this is the first occurrence of that concept in this draft. Section 3.1, second paragraph after Figure 1 Cite a Frame Relay reference for the FECN bit. Moving the [Buck00] citation up to immediately follow "Frame Relay" in the first line suffices. Section 3.2 first paragraph These are Ethernet switches that bury into the Ethernet payload ... bury -> burrow [Spelling checker is missing "read user's mind" feature :-)] Section 3.4 The second paragraph could be improved by citing references for fat-tree and Clos network topologies. Section 4.1, second paragraph Therefore section 4 of [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to configure the ingress of a non-ECN tunnel so that it zeros the ECN field in the outer IP header. non-ECN tunnel -> tunnel that does not support ECN Section 4.1, third paragraph Even if the shim(s) encapsulate a L2 header, it is often possible to find an inner IP header within the L2 header Latter instance of "L2 header" should be "L2 PDU" Section 4.1, last paragraph Instead a companion specification [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has sufficient standards track status to update standards track protocols. sufficient -> the appropriate Authors Addresses Please check these - Pat Thaler's contact info probably needs to be updated. Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 New Mobile: +1 (978) 394-7754 David.Black@dell.com<mailto:David.Black@dell.com> ----------------------------------------------------------------
- [tsvwg] David Black's WGLC review of draft-ietf-t… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe