Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
"Black, David" <David.Black@dell.com> Tue, 10 March 2020 20:36 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 AF7FA3A0CD7 for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=J5V16tCd; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=oYGOHJAr
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 ilTOm9r8dxqW for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:35:57 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 7A1903A0CDE for <tsvwg@ietf.org>; Tue, 10 Mar 2020 13:35:57 -0700 (PDT)
Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02AKQmCC010589; Tue, 10 Mar 2020 16:35:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=btraAlsbLxdV/56Dom8J+aWOM7Wymr0DKfQVE6Y6KSE=; b=J5V16tCdNt+6rVeh5jJZeb086Tg0Cy4UQ/fGUJ59DGni+8Y8Gh/Q1jAvZ0tYAPRYdbfW Z3iwuQjjJbj6BGIqvVZuympeVH9c5QM+oSylRm03aSn7KicS8QD3l5skyGNUA1UR/RCF aJbQoYZ7QlXGrk3YiOF2GrMDDIXhrLHm5Wai9kWFNOmlta9PXjcTSd/DzTS+OL52o20J zquqjcGevdF1m6Vh3UE5/RMlcV7ccaSJuFHqd8boOE6ZcXF3sYsLgTw1V8WitfG7IDIq /k490gDlDoeMMOUh+rbc6W+cx0DArGG09LLkjAuSHk59vQHHgnUUfSQhKuNgjujIe586 KQ==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2ym72dca6a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 16:35:10 -0400
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02AKYXi9072624; Tue, 10 Mar 2020 16:35:09 -0400
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) by mx0b-00154901.pphosted.com with ESMTP id 2ym5rshxah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Mar 2020 16:35:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W1xHRFKi/deHBz/cX7oidylUB/3Z04U+hq4JHHxYpdg2z04rIsscZZvQJD8TMGnorDjSlbYZy8XQA97GWZsXsqki5AQVnhLY2m8KqBsh7NWrXURjCi6wPx5PkOJaay4/Dsx4TcQGIh31z8xK0KG6Yl1iAUJ+Z42i7o8pSLB/SqIyv4UWqfDM5VlROQMkuvrk2d3VxTAS4IiRE7BhgFIPU8WCMNkDUGnX+vWomIhSiK/20ENirdG9LDXIPf0I6+zDDn6KkLH07cJHDuIWT2ERNTDbrIOpLLkAhbw6yYpqVoZEDQ7vedRihZr672F0jyyB6mbF5JUZW1W8VWO/oKLwWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=btraAlsbLxdV/56Dom8J+aWOM7Wymr0DKfQVE6Y6KSE=; b=fk58z/E12//wDCv5v8PFYjoLO32iCo5yESaGBbEdCOQZzL9LPRmbwgvEPiTbb9mvf+VA9Ek2yXriYjrFf/SIPEKdEdSnIeJXX0wQAvEtoKl3jX7biz4f2gsMc2V+LHU0scUP1lmj60GjYJpNDSDbfZ/BXtS36Q7clsDBk3IDhBV9EU0IAotLzhqpv1WXCyB0kk2C4TTd8udl5fXLkG+BTRdIxO8y+e/TkBZhsrRB8lZvObqzlU+je8xZbHtMKdEzAm+jZ32kBZtPy+YlapIy0sx1HQJcI+3GYx02zfhClG1EREeICVji6NdwmFceIRcROt+Vs0VNoOO0slgDFY1nXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=btraAlsbLxdV/56Dom8J+aWOM7Wymr0DKfQVE6Y6KSE=; b=oYGOHJArXe+DOYAm0q01roQNGP8VJb7VWfOkrPZh/jNuTE0+/cbP5PP5AH3y6Hqi+owGSsx5neP/vA2Fakh4SUZG65g7Pt1SATrMSPNNlxhG8u8VhAXz6wMv9W/HB9G3a1p2TtCu/G3mMNZYK+yweCfLKw9Kuo1rxj3uMAWs9ag=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3118.namprd19.prod.outlook.com (2603:10b6:208:154::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Tue, 10 Mar 2020 20:35:08 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::c476:9aac:4d02:477c%5]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 20:35:08 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
Thread-Index: AQHV9wxYb8zHFMAs/km+b19uyubFsahCQ13g
Date: Tue, 10 Mar 2020 20:35:08 +0000
Message-ID: <MN2PR19MB40452EBBC3FB79782C7EDD7183FF0@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net>
In-Reply-To: <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-03-10T20:27:37.7574998Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [168.159.213.214]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 834efc9a-5a50-4fd0-438e-08d7c532861a
x-ms-traffictypediagnostic: MN2PR19MB3118:
x-microsoft-antispam-prvs: <MN2PR19MB311807955D9F994431F7CFE683FF0@MN2PR19MB3118.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(33656002)(7696005)(53546011)(81156014)(6506007)(52536014)(8936002)(8676002)(81166006)(966005)(110136005)(71200400001)(316002)(5660300002)(86362001)(478600001)(2906002)(9686003)(66946007)(55016002)(66556008)(786003)(186003)(76116006)(26005)(66446008)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB3118; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GtyeONqsBDmHPdf53PC+dvG4Ra21ATcpR44BAC/i0Ym6XeklmgeI3DY6R7anB+s8YhU6OpizyzqyY7tEOedtzY5dmD8VEMCuvYnJ5PGeNEl8ZkbxBSD4jXZi9dxXMhdqKjOn+6cAA7kDSJZvzhA5O3iHcSwWdrKFsASYE+5dXb4m05QkFs0r6msJXhgGtLys2z4YgYT52uALkqKw/+N1HwbOFJIEJaZxRMUwAvwxI+o34iwSRif1i4YGGa/N7LvqjQuXmFbi29kLPQhOYJ+mPQA3VYsigUNtOHum+SnhHMQzF+BHG5DRjPkOHOX5gYDJaVgIIpVa4ZPmwcnXmIGzgrq5lG5Wb3eUE5LfC4NdpJYf/QPeitRztBZCL1JAcFfT9iFJ6sL2B89L4jq4haCx3jcSZ6n4l54G0twxXV+km+tN2bhj4HDinqt640fiMPu29sAj04UPpylKTM4LQkIjqZYK29ORPISVgnFAHRq+tosBMk960wS0NrHXWZQZOWaZ
x-ms-exchange-antispam-messagedata: OUoMLfFrioLjF12RJVUIxNot4vmJVm2xEK5iv+G0LVAvRwDBPi73w2LQ7UG5haHbyrqYk2lhqD3kZGCXz9RahroiMgePGcogplvxZGFE4Fsq7hFF21KC2hnuvsWVe+Lya25Gee4PqDMFmzoX3GjSHg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB40452EBBC3FB79782C7EDD7183FF0MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 834efc9a-5a50-4fd0-438e-08d7c532861a
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 20:35:08.4691 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: r1Fj47ncVsPOKU8ewgP+yVrp6krWvOwb5llGXksRf80ybsU21jcfh4+Bq73X3Tp4r9bMPgbD95AynQdiJwqYnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3118
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-10_13:2020-03-10, 2020-03-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 clxscore=1015 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003100121
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003100120
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/muvp47fkZ9NOu8Kz0PLMuyWGz54>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
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: Tue, 10 Mar 2020 20:36:08 -0000
Bob, As draft shepherd, let me suggest an alternate way to think about fragmentation and reassembly that may result in simpler text. The current situation arises in large part from viewing fragmentation and reassembly as being part of tunnel encapsulation and tunnel decapsulation respectively. Instead, I suggest that we view all four of these as separate but related processes, specifically: * A tunnel ingress encapsulates the inner packet and then fragments the resulting (encapsulated) outer packet if necessary for transmission. * RFC 6040 and this document specify the ECN requirements for encapsulation. RFC 3168 specifies ECN requirements for fragmentation. * A tunnel egress reassembles the outer packet and then decapsulates the resulting (still encapsulated) outer packet to produce the inner packet. * RFC 3168 specifies ECN requirements for reassembly. RFC 6040 and this document specify the ECN requirements for decapsulation. Optimized implementations may of course mix encapsulation and decapsulation processing with fragmentation and reassembly processing, respectively, but the results are required to be the same as if the above orders of processing were followed and that processing adhered to the requirements listed above. I think the result will be clearer, and will also make it obvious that nothing new is being required, especially if "RFC 6040 and this document specify" can be changed to "RFC 6040 specifies" in both sub-bullets above. What do you think of this approach? Thanks, --David From: Bob Briscoe <ietf@bobbriscoe.net> Sent: Tuesday, March 10, 2020 2:47 PM To: Black, David; tsvwg@ietf.org Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck) [EXTERNAL EMAIL] David, I admit to curling up into a little ball and trying to ignore this controversy when it arose. Let me try to sort this out now, for both ecn-encap-guidelines and rfc6040update-shim. Back in Sep '19 (quoted at the end) you asked me not to use rfc64040update-shim to update RFC3168's fragmentation behaviour, even if it's the "right thing" to do, given I was saying that there were problems with the RFC3168 approach. Background: Neither RFC3168 nor RFC6040 covered fragmentation & reassembly during encap and decap. So Joe Touch suggested rfc6040update-shim should fix that omission. Seems reasonable enough. However, it doesn't seem right to fix an omission by the stop-gap of: 1. requiring the approach in RFC3168 that we know is potentially problematic. 2. then planning to correct what we write, by updating it in a later RFC. Let's call that approach (A). I don't like that at all. What if step #2 never happens? Fortunately, that's not the only way out of this. I can think of three other ways: B) The compromise text I've drafted below, which states the high level intent of a good mechanism as a SHOULD, and gives an example of how to do it. Then also allows the RFC3168 mechanism as a "MAY". C) Say nothing about fragmentation and reassembly in rfc64040update-shim or ecn-encap-guidelines. Then use a later RFC to update them both (stds track and BCP) with a considered 'correct' approach. ecn-encap-guidelines would still say include what it has always said about re-framing (which is a similar but different subject). D) Convince ourselves that fragmentation and reassembly during encap and decap is allowed to be different from fragmentation and reassembly without encapsulation. Last night, I took approach (B), but with too little time left to discuss it on the list. I scrubbed the offending paras from rfc6040update-shim and replaced them with those below (also at https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#section-5 ). Thinking about it further since last night, I'm now inclining towards approach (C). 5. ECN Propagation and Fragmentation/Reassembly The following requirements update RFC6040<https://tools.ietf.org/html/rfc6040>, which omitted handling of the ECN field during fragmentation or reassembly. These changes might alter how many ECN-marked packets are propagated by a tunnel that fragments packets, but this would not raise any backward compatibility issues: If a tunnel ingress fragments a packet, it MUST set the outer ECN field of all the fragments to the same value as it would have set if it had not fragmented the packet. During reassembly of outer fragments [I-D.ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#ref-I-D.ietf-intarea-tunnels>], if the ECN fields of the outer headers being reassembled into a single packet consist of a mixture of Not-ECT and other ECN codepoints, the packet MUST be discarded. As a tunnel egress reassembles sets of outer fragments [I-D.ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#ref-I-D.ietf-intarea-tunnels>] into packets, as long as no fragment carries the Not-ECT codepoint, it SHOULD propagate CE markings such that the proportion of reassembled packets output with CE markings is broadly the same as the proportion of fragments arriving with CE markings. The above statement describes the approximate desired outcome, not the specific mechanism. A simple to achieve this outcome would be to leave a CE-mark on a reassembled packet if the head fragment is CE- marked, irrespective of the markings on the other fragments. Nonetheless, "SHOULD" is used in the above requirement to allow similar perhaps more efficient approaches that result in approximately the same outcome. In RFC 3168<https://tools.ietf.org/html/rfc3168> the approach to propagating CE markings during fragment reassembly required that a reassembled packet has to be be CE-marked if any of its fragments is CE-marked. This "logical OR" approach to CE marking during reassembly was intended to ensure that no individual CE marking is ever lost. However, an unintended consequence is that the proportion of packets with CE markings increases. For instance, with the logical OR approach, once a sequence of packets each consisting of 2 fragments, has been reassembled, the fraction of packets that are CE-marked roughly doubles (because the number of marks remains roughly the same, but the number of packets halves). This specification does not rule out the logical OR approach of RFC<https://tools.ietf.org/html/rfc3168> 3168<https://tools.ietf.org/html/rfc3168>. So a tunnel egress MAY CE-mark a reassembled packet if any of the fragments are CE-marked (and none are Not-ECT). However, this approach could result in reduced link utilization, or bias against flows that are fragmented relative to those that are not. Regards Bob On 15/09/2019 22:07, Black, David wrote: This email concerns draft-ietf-tsvwg-ecn-encap-guidelines and draft-ietf-tsvwg-rfc6040update-shim, which are being handled together for WG Last Call and RFC publication, and is posted in my role as shepherd and responsible WG chair for these drafts.The current situation is that both drafts are stuck due to a problem with the fragementation text added to the rfc6040update-shim draft. Section 5 on ECN Propagation and Fragmentation/Reassembly was added to that draft in response to a WGLC comment, and it appears to have gone too far in the direction of trying to do the proverbial "right thing". The core of the problem is in these two paragraphs in Section 5 of that draft (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#section-5): As a tunnel egress reassembles sets of outer fragments [I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE markings on the basis that a congestion indication on a packet applies to all the octets in the packet. On average, a tunnel egress SHOULD approximately preserve the number of CE-marked and ECT(1)- marked octets arriving and leaving (counting the size of inner headers, but not encapsulating headers that are being stripped). This process proceeds irrespective of the addresses on the inner headers. Even if only enough incoming CE-marked octets have arrived for part of the departing packet, the next departing packet SHOULD be immediately CE-marked. This ensures that CE-markings are propagated immediately, rather than held back waiting for more incoming CE- marked octets. Once there are no outstanding CE-marked octets, if only enough incoming ECT(1)-marked octets have arrived for part of the departing packet, the next departing packet SHOULD be immediately marked ECT(1). Much as that may be the proverbial "right thing" to do, particularly with the benefit of 20/20 hindsight, that text is inconsistent with the following text from Section 5.3 of RFC 3168 (https://tools.ietf.org/html/rfc3168#section-5.3), as Markku Kojo has pointed out: ECN-capable packets MAY have the DF (Don't Fragment) bit set. Reassembly of a fragmented packet MUST NOT lose indications of congestion. In other words, if any fragment of an IP packet to be reassembled has the CE codepoint set, then one of two actions MUST be taken: * Set the CE codepoint on the reassembled packet. However, this MUST NOT occur if any of the other fragments contributing to this reassembly carries the Not-ECT codepoint. * The packet is dropped, instead of being reassembled, for any other reason. If both actions are applicable, either MAY be chosen. Reassembly of a fragmented packet MUST NOT change the ECN codepoint when all of the fragments carry the same codepoint. The 6040update-shim draft is intended to update RFC 6040, and a number of the tunnel protocol drafts, but it is not intended to update RFC 3168, and hence the above new text (albeit well-intentioned) is a showstopper. Changing ECN fragmentation behavior should be done in a separate draft. Bob (as draft editor) - do you want to propose some new text to the list, possibly after private email discussion with Marco and me to figure out what it needs to say? 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> ---------------------------------------------------------------- -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [tsvwg] Status of ECN encapsulation drafts (i.e.,… Black, David
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Black, David
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- [tsvwg] SCE / L4S and fragmentation (was: Status … Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] SCE / L4S and fragmentation (was: Sta… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] SCE / L4S and fragmentation Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] SCE / L4S and fragmentation Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] SCE / L4S and fragmentation Wesley Eddy
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joe Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… John Leslie
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] SCE / L4S and fragmentation Black, David