Re: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 06 March 2020 18:58 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077E33A0496; Fri, 6 Mar 2020 10:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JXHLH3Ni; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BbXAEVVK
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 D-9CXBEfE57E; Fri, 6 Mar 2020 10:58:12 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27D03A0484; Fri, 6 Mar 2020 10:58:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7682; q=dns/txt; s=iport; t=1583521091; x=1584730691; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jq7hncoj/RpXK3+G9tbH5rOCc4BVVnBb4CHY8Qwbg00=; b=JXHLH3NiDmn9pclxPN12YlntlCsWMSXTyGoUWXd9HU5C2wmlNWuOkM4F 7MeXpD2K6sAw7vSKkxaSxxnXZrif/5jdrTQ6jzdgCoS0vuzmvZCrTaUHn c3W9WxFpyKjp1Y4P6xIVDJnuiKb+expuhyp1day0M3Lzc6v+d6islsdK1 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOmpL/hem1UpWZXfDybJB68ETlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZBQDsm2Je/4sNJK1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVCQsBWxYIAQLKoQVg0YDimmDYJcUglIDVAkBAQEMAQEjCgI?= =?us-ascii?q?EAQGEQwIXgXckOBMCAwEBCwEBBQEBAQIBBQRthVYMhWQCAQMSEREMAQE3AQ8?= =?us-ascii?q?CAQgaAiYCAgIwFQULAgQBDQ0agwWCSgMuAQ6ddAKBOYhidYEygn8BAQWBMwK?= =?us-ascii?q?DUBiCDAMGgQ4qhSGHBxqBQT+BEUeCGDU+gmQCAhqBISqDDzKCLI1zgnWPfo5?= =?us-ascii?q?PcAqCPJcCgkmIIYROhzCETYNMiyqbUQIEAgQFAg4BAQWBaSKBWHAVgydQGA2?= =?us-ascii?q?OHQkDFxWDO4UUhUF0gSmNDIJCAQE?=
X-IronPort-AV: E=Sophos;i="5.70,523,1574121600"; d="scan'208";a="736093135"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Mar 2020 18:58:09 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 026Iw92Q011785 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2020 18:58:09 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 12:58:09 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 13:58:08 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Mar 2020 12:58:08 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DQowTcMD8rk6JQuNVSmW7rPeZkj4Sk7aCsj5Dbm6xEtk7U9lEkgLTyDV0NIMZe?= =?utf-8?q?Uq+CNTepaIYkPyqWWSLXKP2ZJtuXJFOxQ2Vq0jnzgdbI1ZWJ3mxGD5jTJLVMcRGlc?= =?utf-8?q?YUnPq02/sqEcNwMS2DUnqm9ws4IwT4ufASCLjIEtd6EdnHfyvHUjUOOjBJbV5MU6w?= =?utf-8?q?x/mhCGy9qWeBIUGIzpw9+5lj4ZOjD34qxgwudgg/36j/NwQbEvx/6gwI+BE+T37dU?= =?utf-8?q?5Z081Y5FUJ6vRxhbGsAS004OFHb4IFKJQLDJbNnLAnlqT28cMhqiTW7fUC5Y78HYk?= =?utf-8?q?W1c5Xy+nsyzpNRqXJKBCg=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DJq7hncoj/RpXK3+G9tbH5rOCc4BVVnBb4CHY8Qwbg00=3D=3B_b=3DdN6oZy?= =?utf-8?q?Wp4x9+Ox5G/hy3LlME9JdafrbD4ET6Iq+K0kHxJhVIknFnSvpY5BDJnFSpGLiVnIb?= =?utf-8?q?lGwVguV1F4rjHXt+AtqsKoy1rRSK4jYWqhpXD5gQtGSNee5JuNv/FThvlZsLCIC3o?= =?utf-8?q?Hn7xDySoXLxp+VnH6vPdJTqbnAg6EbIZjsw4MWZ6rSl0Y3pCXHN7jM/IWrkbYUzQL?= =?utf-8?q?PbPKpnPdg7vSiRWqdL76FgdniwvSCMaHvxbfp8thzPUX5E4xor3fH02cgJNNmTMVJ?= =?utf-8?q?59p5NR74OAzVdJm81icQoMXdvVVec2l6p6dql7OBPiblBdsdHO5t+ACTVKr+foiR2?= =?utf-8?q?/thIRBHe9Lw=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DJq7hncoj/RpXK3+G9tbH5rOCc4BVVnBb4CHY8Qwbg00=3D=3B_b?= =?utf-8?q?=3DBbXAEVVKIeD23C29Mzl0mRhavH6IoLRnWwcaEa5NVEqlzz/SdMIUYU6rt8IYbH?= =?utf-8?q?wdF4BMwGKCU2epEHW0jyDm2VbIolj+TFRcMRVnXZYDeTqXwqCFkqOe/1We9IQywVA?= =?utf-8?q?QHpmPKzuhfy5uCJkkG4Z8FhCYI5SrDpnFLYcyNrz45Ec=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4549.namprd11.prod.outlook.com (2603:10b6:208:26d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 18:58:08 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24%6]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 18:58:08 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-6lo-fragment-recovery-13=3A?= (with COMMENT)
Thread-Index: AQHV5yWD5Xj09hNHsEicT3TqKQcwBag6KyEw
Date: Fri, 6 Mar 2020 18:56:40 +0000
Deferred-Delivery: Fri, 6 Mar 2020 12:42:00 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB356508B020B4D2F877E91107D8E30=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158211762351.23776.5618697293473954460.idtracker@ietfa.amsl.com>
In-Reply-To: <158211762351.23776.5618697293473954460.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:fc31:4bd4:6411:8e6b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0613890f-46da-41a3-5ed4-08d7c2004f2e
x-ms-traffictypediagnostic: MN2PR11MB4549:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB4549C7F53EA69011E934658DD8E?= =?utf-8?q?30=40MN2PR11MB4549=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDM3NjAwMikoMzk2MDAzKSgzOTg2MDQwMDAwMikoMzQ2?= =?utf-8?b?MDAyKSgxMzYwMDMpKDE4OTAwMykoMTk5MDA0KSg2NjU1NjAwOCkoMjkwNjAwMiko?= =?utf-8?q?66446008=29=2866476007=29=2866946007=29=2864756008=29=28712004000?= =?utf-8?b?MDEpKDY2NjYwMDQpKDMzNjU2MDAyKSg4OTM2MDAyKSg4NjM2MjAwMSkoNDMy?= =?utf-8?b?NjAwOCkoMzE2MDAyKSg5Njg2MDAzKSg1NTAxNjAwMikoOTY2MDA1KSg1NjYw?= =?utf-8?q?300002=29=286506007=29=2852536014=29=28478600001=29=2854906003=29?= =?utf-8?q?=28110136005=29=2876116006=29=28224303003=29=2881156014=29=288116?= =?utf-8?q?6006=29=287696005=29=28186003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4549; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?Hn8PYBJMvay1nbmDfCw7bo8QXVwh0vG?= =?utf-8?q?E+YXEQ/hgBtIPLwXbLJiX0NzLbWG9HX2HJ864KdsMkq86p5j9DHIQ81UzPi8gUdLD?= =?utf-8?q?jNBfTaMCerxKLAw0kTMT9CglOkqKhRay1FEg6I6GWSZVvgc4MUqzBY5Ez6POIV1b7?= =?utf-8?q?+wVuW5WdTijQoe3eguCES4jDCG047s7n9gZKjyjWJjzeq33CinUqoxVKtelqwxUao?= =?utf-8?q?oJDr0o5zXCYWPPrl7B/v8mLHRHTkf87kTR9KOUDYXeRW6GH+Jzyqq30S5iGcDbenR?= =?utf-8?q?7YonFXmNX0SsWpef0jDlyNOI9B3P2UzvRR5TeLSNUPSHTX/j1vhIeDDaXZ+fxbwNr?= =?utf-8?q?P7+Sit8lo1QbBY49+AsgWYECaE0os4ih5UQMZOHEqg+j1+wwyKY6QZaZwEhDGt8AA?= =?utf-8?q?jXi7Oz4boU9SXugTG0uQ73722phGSlFtNOxTxjT7dOvR/GgZyPMKw8btfb6qpi5gC?= =?utf-8?q?rs4UDmVk4oPdpwu8BHiNbqqBwcFaKT0Xl1I6oKr2/bQelq9A=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?IuzkC+8ZQ1KzQ1DFoBpjtZqAVA7Sw1?= =?utf-8?q?AU6Rga8iedckJXbAYbKs9PqVVPqkccoHUNLAkpWlv3x+8Ch1MAyYZNjBncH+0pahr?= =?utf-8?q?SG9NImJQwAYOKgZzfKTsq9HvQRvVbaKVAp+qh3fkgnSXsXggRK8RSBW5P+lrM02Gb?= =?utf-8?q?sXTy2jhyiqt14FzX9BxdzYa9xAfyUyp/Bv1ApX98FGkNBYxTXcErBA=3D=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0613890f-46da-41a3-5ed4-08d7c2004f2e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 18:58:07.7113 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?6oUmJPO6PAR4TZI/dnitp?= =?utf-8?q?RE2VnSn+Jl76yNmUTSvxQ+uOLiw5pfZ71Xh/dQNdoF6FObvBS3BBxD2LySBViPHMw?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4549
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/NjVNTmLPJbdXViIM5-aULQ_pzG8>
Subject: Re: [6lo] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?6lo-fragment-recovery-13=3A_=28with_COMMENT=29?=
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 18:58:14 -0000

Hello Eric:

Many thanks for your review!

Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14  that I just published 

Let's see below, and please let me know if the proposed changes work:

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> == COMMENTS ==
> 
> A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header
> Chains" is applicable ?
> 
> -- Section 4.2 and Section 7.1 --
> Should default values for the inter-frame gap be given ?

We discussed this in the minimal fragment review. Initially there was no other draft so this really introduced the concept. Now all the normative text moved to minimal.
So it makes sense to make a change here:

before

   This specification introduces a concept of an inter-frame gap, which
   is a configurable interval of time between transmissions to the same
   next hop.  In the case of half duplex interfaces, this inter-frame
   gap ensures that the next hop has completed processing of the
   previous frame and is capable of receiving the next one.
	
After

   [I-D.ietf-6lo-minimal-fragment] requires that a configurable interval
   of time is inserted between transmissions to the same next hop and in
   particular between fragments of a same datagram.  In the case of half
   duplex interfaces, this inter-frame gap ensures that the next hop is
   done forwarding the previous frame and is capable of receiving the
   next one.

end



> 
> -- Section 5.1 --
> With 8 bits in the Datagram_Tag, this means that a node can only
> transmit/forward 256 packets over a link. While this seems suffisant, did the
> author make some investigation on this limit? The text should also state what
> to do when the 8 bits are not enough.
> 

A typical 6LoWPAN node have memory for one or a few packets. Having 256 packets that transit in the fragmented form over a same hop at the same time seems very far from the capabilities of current 6LoWPAN nodes. The trend for new MACs is to support the IPv6 Min MTU, making 6LoWPAN fragmentation a thing of the past. So I believe we're good. 

I'm adding the last sentences of the following text in the introduction:
"
   "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
   specifies the general behavior that all FF techniques including this
   specification follow, and presents the associated caveats.  In
   particular, the routing information is fully indicated in the first
   fragment, which is always forwarded first.  A state is formed and
   used to forward all the next fragments along the same path.  The
   Datagram_Tag is locally significant to the Layer-2 source of the
   packet and is swapped at each hop, more in Section 6.  With this
   specification the Datagram_Tag is encoded in one byte, and will
   saturate if there are more than 256 datagram that transit in the
   fragmented form over a same hop at the same time.  This is not
   realistic at the time of this writing.  Should this happen in a new
   6LoWPAN technology, a node will need to use several Link-Layer
   addresses to increase its indexing capacity.
"


> -- Section 5.2 --
> I suggest to mention that the use of the Datagram_Tag field will be described
> in section 6.

Works for me. In fact, I pushed that up to the introduction, see the text above.


> 
> -- Section 6 --
> I find it weird to read in the same paragraph "The RFRAG Acknowledgment can
> optionally carry an ECN" and later "MUST echo that information by setting the
> 'E'". I am not a native English speaker but may I suggest to replace the first part
> with "The RFRAG Acknowledgment has a ECN"

Yes, done.

> 
> -- Section 6.1.2 --
> "An implementation may receive overlapping fragments as the result of retries
> after an MTU change." Is this a security risk (RFC 8200 forbids overlapping
> fragments but this is a different layers) ? I also suggest to make it a normative
> "MAY" or "MUST accept".

I got a similar comment in Ben's review on this : )

"

   [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint
   stores "the actual packet data from the fragments received so far, in
   a form that makes it possible to detect when the whole packet has
   been received and can be processed or forwarded".  How this is
   computed is implementation specific but relies on receiving all the
   bytes up to the Datagram_Size indicated in the first fragment.  An
   implementation may receive overlapping fragments as the result of
   retries after an MTU change.

"


> 
> -- Section 7.2 --
> Should the network observation installs global states or per destination states
> ? E.g., typical IP implementations maintain a per destination Path MTU cache.

I guess the same here, this is per destination for each sender and per sender for each destination.

"
   The management system should monitor the number of retries
    and of ECN settings that can be observed from the perspective of
    both the sender and the receiver with regards to the other end-point.

"
> == NITS ==
> 
> -- Section 7 --
> Is it "Kbps" or "kbps" ?

Long as the b is lowercase (indicating bit) I believe we're safe. But back to SI, Kilo is uppercase (because it is a multiple of the unlike milli or micro) so I favor Kbps. 

Please let me know if we're good with the above,

Again many thanks, Eric!

Pascal