[tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

"Black, David" <David.Black@dell.com> Tue, 08 October 2019 19:52 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E8094120129 for <tsvwg@ietfa.amsl.com>; Tue, 8 Oct 2019 12:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=CD+Prll0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ZL135n85
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1XLpLc1-FAHB for <tsvwg@ietfa.amsl.com>; Tue, 8 Oct 2019 12:52:26 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com []) (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 65AE41200EF for <tsvwg@ietf.org>; Tue, 8 Oct 2019 12:52:25 -0700 (PDT)
Received: from pps.filterd (m0170389.ppops.net []) by mx0a-00154904.pphosted.com ( with SMTP id x98HFNnR013481 for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:52:24 -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=/VrMfgYmPt3OrdGJY7jEaNQWNmqFugHEfQje7yffMgM=; b=CD+Prll0yf3j3eZZDh7kVwRGmZxtMjZ7Iio47XfgnVf6YG6rVjhE1Eo1neatWHZh5mVd pP6xpLkcNfIAzfax9Fu5lsti4ldiDIEKxzKFZYwgzKqEjzyEv++rbkRfHF4cFPNiAFPV rs0tozSeOiX2ABbxVHDIE8HNQb7AuGew+38AH0uOsQ8Vaf3BekqL7b+HeUaOMaokWCQd 6dRcw8mIm6QvKjFV6qGbZ9UEZha/hpPym104hcLtTiynUgBMlfcTdAKiorMjxLbU2+or VIrztXf5Lv0P/paUqvHcm0S78o+7R5fqXWs3myLMAPPIu6TtEGbK5YORuKOgpkFoDO/j ww==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com []) by mx0a-00154904.pphosted.com with ESMTP id 2veq6s7gdj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Tue, 08 Oct 2019 15:52:24 -0400
Received: from pps.filterd (m0142693.ppops.net []) by mx0a-00154901.pphosted.com ( with SMTP id x98JgZlK079518 for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:52:24 -0400
Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [] (may be forged)) by mx0a-00154901.pphosted.com with ESMTP id 2vguke687j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsvwg@ietf.org>; Tue, 08 Oct 2019 15:52:24 -0400
Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com []) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x98JqC6p011130 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:52:22 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com x98JqC6p011130
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1570564342; bh=Pbq7F+RxZ4nnRd8Z4ucgojVsyxU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ZL135n85nsxFs5ghRMXx6ArPjbQLVwnd/y3YXN5GAz4tW42roDLNi271gQ8iarJnX XTX50qNILzU0svIWUdynSVlszXLdg0KwZbW4yZfatOe0PJTLZZ64jfAUr9/8N0aVYE QtCRXBdft1+O7Dbiy8ufZm4H5qTqUphShyqT1Sn8=
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com []) by maildlpprd54.lss.emc.com (RSA Interceptor) for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:51:54 -0400
Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com []) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x98JpqHU019385 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:51:52 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([]) with mapi id 14.03.0439.000; Tue, 8 Oct 2019 15:51:52 -0400
From: "Black, David" <David.Black@dell.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text
Thread-Index: AdV+EW9lSeutSdIXSx+HNH12yzDHrwAAFawA
Date: Tue, 08 Oct 2019 19:51:52 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
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=2019-09-23T21:57:25.5453570Z; 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: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936307662EAMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-08_07:2019-10-08,2019-10-08 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxscore=0 suspectscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=931 bulkscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910080151
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 suspectscore=0 phishscore=0 impostorscore=0 mlxscore=0 malwarescore=0 clxscore=1015 adultscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910050075
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FsyZBa7-VvEZ5c9LqutmsflkdpU>
Subject: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text
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, 08 Oct 2019 19:52:29 -0000

Context: Both draft-ietf-tsvwg-rfc6040update-shim and draft-ietf-tsvwg-ecn-encap-guidelines are currently stalled due to incompatibility between the new fragmentation/reassembly text in draft-ietf-tsvwg-rfc6040update-shim and RFC 3168.  Towards getting both drafts moving again ...

This note suggests text to bring Section 5 of draft-ietf-tsvwg-rfc6040update-shim (ECN Propagation and Fragmentation/Reassembly) into alignment with Section 5.3 of RFC 3168 (Fragmentation).   While the existing Section 5 of the rfc6040update-shim draft may be well-intentioned, that draft is not an appropriate vehicle for changing RFC 3168's reassembly requirements.   If those requirements are to be changed, a separate draft focused on fragmentation and reassembly (overall, not just for tunnels) would be appropriate.

For context, here's the crucial text from Section 5.3 of RFC 3168 that the rfc6040update-shim draft needs to align with:

   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

      * 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.

Section 5 of draft-ietf-tsvwg-rfc6040update-shim gets off to a good start - the first two paragraphs of that section are fine and should be retained:

   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.

**NEW**: Beyond those first two paragraphs, I suggest deleting the rest of Section 5 of the rfc6040update-shim draft and substituting the following paragraph:

   As a tunnel egress reassembles sets of outer fragments

   [I-D.ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#ref-I-D.ietf-intarea-tunnels>] into packets, it MUST comply with

   the reassembly requirements in Section 5.3 of  RFC 3168 in

   order to ensure that indications of congestion are not lost.

It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the "reassembles sets of outer fragments" lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.


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