Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 07 February 2020 15:03 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 4C4B7120890; Fri, 7 Feb 2020 07:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=LrKqqQZH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BrSy2wfX
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 xgzhfGHVQymj; Fri, 7 Feb 2020 07:03:31 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFD912080D; Fri, 7 Feb 2020 07:03:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10880; q=dns/txt; s=iport; t=1581087811; x=1582297411; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZUiRyT2SHyCRZ8vIfbVa/6HdyleFNBTv70xPZZVhjCI=; b=LrKqqQZHJAbkzmqmVr8k4bWR5vBtjbjXgXPw4JppTZ6XbRasv23uf9Xb MJgH4GOiAvQikdURYRusqru+gbSirN731dP/ui461FS4Udj1GyEcGtfJs y20hnqDMrqLdxwBrvh+2Mcsc4owFiVtNz8nNPIy5zjHn7mx92PJdcUfA4 0=;
X-IPAS-Result: =?us-ascii?q?A0C3CQDSej1e/4oNJK1mHgELHINPUAVsWCAECyqEFYNGA?= =?us-ascii?q?4p+gl+YEoJSA1QJAQEBDAEBIwoCAQGEQAIXgiwkOBMCAwEBAQMCAwEBAQEEA?= =?us-ascii?q?QEBAgEFBG2FNwyFZgEBAQMBEgsGEQwBATcBBAsCAQgSCAImAgICMBUCDgIEA?= =?us-ascii?q?Q0NGoMFgkoDDiABAgyjXAKBOYhidYEygn8BAQWBMwKDeRiCDAMGgQ4qhR+HB?= =?us-ascii?q?BqBQT+BEUeCTD6CZAICGoErIIMOMoIsjVQSgnWPY45IcAqCOoMziWGJU4JIi?= =?us-ascii?q?BGQNo5kl0CDZQIEAgQFAg4BAQWBaSKBWHAVgydQGA2OHQwXFYM7hRSFP3SBK?= =?us-ascii?q?Y0/AQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AUm0/qBOYgCfNaS44Gosl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUJ+kNUffqXCz8zMeXw?= =?us-ascii?q?7nO1opdMLyHIOaz9yt0Py/8IHSZAMOgyehZbR1L1O9qgCD/sIXmoBlbK02z1?= =?us-ascii?q?PFpXZTM+JR2StkKEmSkBD1+srVntZ7/j5Vuu49+sIISqj8c6kiBbxfFyg9cm?= =?us-ascii?q?0=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,413,1574121600"; d="scan'208";a="409140845"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Feb 2020 15:03:30 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 017F3UQ7020976 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2020 15:03:30 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Feb 2020 09:03:29 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Feb 2020 09:03:29 -0600
Received: from NAM12-MW2-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, 7 Feb 2020 09:03:29 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JIlWN+IXzpaocOMONvADgx2qMFi0QtiQxLiBHUGfK9fJdJKx9L8zz4aOtTPxxF0dEpYbJKDzsugnMJ110euf+fmyb+IDB2wJxBigHJE4dgpWbl40UY2ACURHf7ehyCp1l9s4jUEXc41SirB2t0Uq1187OtzbZ95wlZTZ/eEM/1qpTZpIDE52rE4nwsK07tM0kmOnccHaObxzvRWqafnUqJNHmZdV/MTEPaef5Sb/tUvDeMad9h4Ze5ohDNi30VezUbM46gBasTQrjLxLabIeySqRKJXWGg4N5Fch8zkk4nK7hbMiZser4CYBolWBFw7dU9tCdD+CiBVSazM+cGcTbQ==
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=ZUiRyT2SHyCRZ8vIfbVa/6HdyleFNBTv70xPZZVhjCI=; b=GggbbMEkeK3Mrz4vh2dXKVGDFrhrIFBz39Y2Spx/oiEpzakdLMSJ8E3ybJw6Dx9jgc2HuWuj4VbLImaRNJDan01EmoEK+TT6u/Kyj8YHdFEBTz4DHHYkdiuCvjJ0Qy0KY+CBqLSq4lIkiPjhrnQRtFr3yf4NVQVUxOT05ZRWRgZdUik6CiPu73uuhbH/GZy1DIqKy+XjYiDWJwpxtMZvRPFZCphFGSEDW15lTz6L5/bCcUfvzk2eUTCyMr94HbNylDDMXQ+vUKV+9YAJ1KYu+g9k4ACFBR1B//idxoVVQWGZHGqGLNQCloJqEP7dH0uv7NKdeG7uHv8H3ITsxI1+UA==
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; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUiRyT2SHyCRZ8vIfbVa/6HdyleFNBTv70xPZZVhjCI=; b=BrSy2wfXQEx2uMGiA1eYNycxC2BcnGDlMBPjJqy1wXmJmsHszcHpqbZtiOe0/aoxpF9FseuU9yMkaqbq/Kulr3BUnXdctDGxh14O7KOXj0PG/9xz/CRgQNjFDQ7HDgzkJ7esNJix8fEk7wA91/kdrUKWpREE+vLMuWzDBI573nA=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3773.namprd11.prod.outlook.com (20.178.253.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23; Fri, 7 Feb 2020 15:03:28 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2707.024; Fri, 7 Feb 2020 15:03:28 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-minimal-fragment@ietf.org" <draft-ietf-6lo-minimal-fragment@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)
Thread-Index: AQHV3XxgNejdBwUZOESPeqAuBOg9dKgPwn0A
Date: Fri, 7 Feb 2020 15:03:23 +0000
Deferred-Delivery: Fri, 7 Feb 2020 15:02:19 +0000
Message-ID: <MN2PR11MB35651E4392668D57EE8CBD78D81C0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158105542542.16105.11730811173407473905.idtracker@ietfa.amsl.com>
In-Reply-To: <158105542542.16105.11730811173407473905.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: [2001:420:44f3:1300:41e7:7725:e525:b2e8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 08d10680-c5cf-4469-a99f-08d7abdee34c
x-ms-traffictypediagnostic: MN2PR11MB3773:
x-microsoft-antispam-prvs: <MN2PR11MB37732FA81DE210F5492875F3D81C0@MN2PR11MB3773.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0306EE2ED4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(199004)(189003)(4326008)(86362001)(55016002)(9686003)(5660300002)(186003)(8936002)(6506007)(81166006)(81156014)(8676002)(966005)(33656002)(2906002)(478600001)(7696005)(110136005)(71200400001)(316002)(54906003)(6666004)(66574012)(66556008)(64756008)(66946007)(66476007)(66446008)(52536014)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3773; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: Z4OMIq/Pc04dZTSovmPR+BKCu93DUx3LIyv8uolVfiZleleSxE8PKXyCfF05DNWXbfLnFR6I4oIXHm8Uj5wNs/KdLBldPA8ImAjbpzh03h5yb8EnIir+YSrjjKoFEsJL/AA7Cabv7zYWOqP582U988vDHtqCpu6A2Oah8M/GOZnICJf+9WYNoY4SZPppgZi1jg+3r9ZEf96ZRPvSsC6kQuzRiHX/TGcwfrSoy8Qcfn6s7a5QvMU3InZyCR3EsTeMXutQWVEi5HhWxiN4afQHCllatil4qSCdvck5igAg5wyFpcs3NPQhap4gveuN1JNW7PnAh2GUVJuqTm5ZBiaXAFdCGltgN5VoPwt3kZ+QYYI4CsXDaPaYBzZSsMHxP61ZeSQ9R10YuDK/frm3Pf2ZGlq/GEXUxdyKa8satLvYBOlAetUwlHZK0UuR4tiTljb7WZgPkIce3y3gtxdCJpHhpjOXdZl7bf8a3C0INaR5eI39dqD5JSFLwXr2DySPlTCqnIms6TGUOUjJPQvirKKvUw==
x-ms-exchange-antispam-messagedata: KIHw+ltQObqGyjPRQ0NFinTo/M5b7349mAIOJ0qxQ2PQFxtlDnd2VMuGT/658gRZyCPnWfNXOZoQhgktX3kScFOeG92PtsfFICSc3bMOkGnUdKibO6NO4Aq2LiPGQpSf5KNUYHciWIsXt6+m4FKWhn2fWAdq9qXfb+XotkhPYOeMWk9paK5/UrbzZ3aQyanz1VqYynGQ04GcPrN65hV/8A==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 08d10680-c5cf-4469-a99f-08d7abdee34c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 15:03:27.9356 (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: /k/svAaf6ln9yBD1QFx+0t/pyByumlr76080MsvGlQLRDGsg9GvNoayW8ZOpDWt89T89gwWeRWk+80uHUyFLUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3773
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/swAM7Kxv6WOQIUzSS6YdoWQnvrE>
Subject: Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)
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, 07 Feb 2020 15:03:35 -0000

Hello Barry:

Many thanks for your review!

I published a new version with the outcome of this first pass, so you can easily check the changes in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-11 

Please find the discussion below:
 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for an interesting and well-written document.  Just a batch of
> editorial
> comments:
> 
> — Section 2.2 —
> 
>    poor network behavior and, occasionally, trouble at application
>    layer.  That experience led to the definition of "Path MTU discovery"
>    [RFC8201] (PMTUD) protocol that limits fragmentation over the
>    Internet.
> 
> This is missing two definite articles (“the”), one after “trouble at” and one
> after “definition of”.
> 
>    "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
>    threats that are linked to using IP fragmentation.  The 6LoWPAN
>    fragmentation takes place underneath, but some issues described there
>    may still apply to 6LoWPAN fragments.
> 
> I think this makes FRAG-ILE a normative reference (necessary security issues).
> It would also be useful to have a “see Section 7” forward pointer here, so it’s
> clear that the specific issues are discussed later in this document.

It was never published and never will be, so procedure-wise that's calling for trouble.
The paragraph now looks like:
"
   "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
   threats that are linked to using IP fragmentation.  The 6LoWPAN
   fragmentation takes place underneath, but some issues described there
   may still apply to 6LoWPAN fragments (as discussed in further details
   in Section 7).
"
Works?

> 
>    Readers are expected to be familiar with all the terms and concepts
>    that are discussed in "IPv6 over Low-Power Wireless Personal Area
>    Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
>    Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4
>    Networks" [RFC4944].
> 
> I think this makes 4919 a normative reference (necessary terminology and
> concepts).

A downref but OK, I'll trust an IESG review on this : )


> 
>    Quoting the "Multiprotocol Label Switching (MPLS) Architecture"
>    [RFC3031]: with MPLS, 'packets are "labeled" before they are
>    forwarded'.  At subsequent hops, there is no further analysis of the
>    packet's network layer header.  Rather, the label is used as an index
>    into a table which specifies the next hop, and a new label".
> 
> There’s a quote mismatch here: you should not end the quote after
> “forwarded”... but there should be a paragraph break after “forwarded.”,
> which makes the quoting awkward.  I suggest handling the quote differently
> and eliminating the need for awkward cross-paragraph quotation.  So it
> would look like this:
> 
> NEW
>    "Multiprotocol Label Switching (MPLS) Architecture" [RFC3031]
>    says that with MPLS, 'packets are "labeled" before they are
>    forwarded.'  It goes on to say, “At subsequent hops, there is no
>    further analysis of the packet's network layer header.  Rather, the
>    label is used as an index into a table which specifies the next hop,
>    and a new label".
> END

Great! Adopted : )	

> — Section 2.3 —
> 
>    This specification uses the following terms:
> 
> I would say it “defines” these terms, no?

Not really, they appear in RFC 4944, but ok

>    6LoWPAN endpoints:  The nodes in charge of generating or expanding a
>       6LoWPAN header from/to a full IPv6 packet.  The 6LoWPAN endpoints
>       are the points where fragmentation and reassembly take place.
> 
> I gather that the usual case is that the 6LoWPAN endpoints are the first and
> last nodes in an unbroken string of 6LoWPAN nodes, yes?  If that’s correct, I
> think it would add to easy understanding if you said that.  (And if it’s not
> correct, we might want to figure out why I got that impression.)

Which gives:
"
   6LoWPAN endpoints:  The 6LoWPAN endpoints are the first and last
      nodes in an unbroken string of 6LoWPAN nodes.  They are in charge
      of generating or expanding a 6LoWPAN header from/to a full IPv6
      packet.  They are also the points where the fragmentation and
      reassembly operations take place.
"

> 
> — Section 4 —
> 
>    4. Limits of Per-Hop Fragmentation and Reassembly
> 
>    There are at least 2 limits to doing per-hop fragmentation and
>    reassembly.  See [ARTICLE] for detailed simulation results on both
>    limits.
> 
> Should this be “limitations”, rather than “limits”?  It seems so.  Also
> throughout Section 6.

We get:
"
   There are at least 2 limitations to doing per-hop fragmentation and
   reassembly.  See [ARTICLE] for detailed simulation results on both
   limitations.
"
And later, changed to caveats on occasion, see:
"
   Virtual Reassembly Buffer (VRB) is the implementation technique
   described in [LWIG-VRB] in which a forwarder does not reassemble each
   packet in its entirety before forwarding it.

   VRB overcomes the limitations listed in Section 4.  Nodes do not wait
   for the last fragment before forwarding, reducing end-to-end latency.
   Similarly, the memory footprint of VRB is just the VRB table,
   reducing the packet drop probability significantly.

   There are other caveats, however:

"

And

"
  The severity and occurrence of these caveats depends on the Link-
   Layer used.  Whether they are acceptable depends entirely on the
   requirements the application places on the network.

   If the caveats are present and not acceptable for the application,
   future specifications may define new protocols to overcome them.  One
   example is [FRAG-RECOV] which defines a protocol which allows
   fragment recovery.

"
Does that work?

> 
> — Section 5 —
> 
>    error and refrain from creating a state or attempting to forward.
> 
> Make it “refrains”.

done


> — Section 6 —
> (Change “limits” to “limitations” throughout the section.) Doesn’t this
> section need LWIG-VRB to be a normative reference?

I do not think so. The whole idea in this section was that the text would be self-describing. 
People are free to dig in the LWIG spec but that is not needed to understand this text. 

> 
>       because the IP header is required to route the
>       fragment and is only present in the first fragment.
> 
> This sounds as if the IP header has to do some routing.  If you say “is required
> in order to route...”, that ambiguity goes away.

done


> 
> — Section 7 —
> 
>       along a path, but each node suffers a lesser hit. this is because
> 
> Capitalize “This”.

Done

> 
>       An implementation MUST protect itself to
>       keep the number of VRBs within capacity, and that old VRBs are
> 
> You need another word before “that”: maybe “ensure”?

done
	
> 
>       This sounds
>       difficult and mostly useless in a 6LoWPAN network since the
>       fragmentation is not end-to-end.
> 
> “Sounds”?  “Is”, I should think; no?

applied


> 
> — Section 9 —
> 
>    Also many thanks to Georgies Papadopoulos
> 
> I believe it’s “Georgios”.

Oups : )

> 
>    and Francesca Palombini For their constructive
>    reviews through the IESG process.
> 
> Lower-case “for”.  And did Sarah, Joerg, and Francesca really review this
> through the IESG process, when the IESG process is just now starting?

Changed to

"
for their constructive reviews through the IETF last call
   and IESG process.

"

Again many thanks Barry!

Pascal