Re: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 30 August 2019 11:44 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 692F81200B6 for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 04:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_HI=-5, 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=IWCNUbfa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E65sMx2X
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 bPjLaUfv295H for <6lo@ietfa.amsl.com>; Fri, 30 Aug 2019 04:44:30 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E49112003E for <6lo@ietf.org>; Fri, 30 Aug 2019 04:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32004; q=dns/txt; s=iport; t=1567165470; x=1568375070; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=T0pPts9tuxFM6gtNEZMAYk2INp+9Ft5ZnL5CmnwiWa0=; b=IWCNUbfawPXuVUgLEXg4R2UpyTpXi02X7xzX6JpAKdqZXicXlG9EDFoV GPnm3j0eelU/c7LltucIcBODUIBO+y8mmN11wwkhJBbC8Zw732KWKa70G bQw05nRs+esCeeta4tMQSFNlSAGTE+uNcnrDfT6b8l6IaUMHG6qqqwY8J o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AoF2W7RBcUI2wBT/mE0v2UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AAAMC2ld/5tdJa1cChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVYCAQEBAQsBgRUvJCwDbVYgBAsqhCGDRwOKc02Ze4JSA1Q?= =?us-ascii?q?JAQEBDAEBJQgCAQGEPwIXgkkjNwYOAgMIAQEEAQEBAgEGBG2FLgyFSwIEEhE?= =?us-ascii?q?KEwEBJRMPAgEIDioKAgICMCUCBAEaGoMBgR1NAx0BAgyhDwKBOIhhc4Eygnw?= =?us-ascii?q?BAQWFDxiCFgMGgTQBhH+GeBiBQD+BEUaBTn4+gmEBAQIBgTMtK4JeMoImjyi?= =?us-ascii?q?FHJdPCoIfhnCOAoIyhzaKWIQijXKHc5BRAgQCBAUCDgEBBYFmIoFYcBWDJ4J?= =?us-ascii?q?Cg3KFFIU/cgGBKI1KAQE?=
X-IronPort-AV: E=Sophos;i="5.64,447,1559520000"; d="scan'208,217";a="322281315"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 11:44:29 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7UBiTAX002988 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 11:44:29 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, 30 Aug 2019 06:44:28 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 07:44:28 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 06:44:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QjzI8SMeDs3Zgw0RjXqMDkq8I3KXCc++T5LMuXpJWwdCblJrO2FupZCmzrYgcIZeKKbIMkLUR64C7SFaP1Dgp9RYZZnc8P+QhW+uGu8xzlhcWOgJeQaQfx0YgIHf+idqw+VE8IdnP7xMkoI9ntFC5NXXB627LYaM3h0hhHLSi6Rs0cb1mWMTTlbU3chAoyvQFzoPyYnmbJYLgfibrwgA0cftdjVQyJN09h/e5gaooaairhzWgpNUsCdb1wnKumETCrFTT3rhAsndfsPgLgNBljRJl0w0bWTz9shi/bN4NLN6T/RpLL0QIFHyCU2Z4E+oBJ39mMsJMarPyQsKHLCYGQ==
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=T0pPts9tuxFM6gtNEZMAYk2INp+9Ft5ZnL5CmnwiWa0=; b=CmCylWw9razfa7powHY+TxH6BEbZxRduIl/vcp5lAAEDtgOklVGqmtPhN0fWB2/soHWvXufPRshoAXxpmK0QqVcdcE6xzUSTmgAXG5cktefYhEbkdtOu0vD1JtNzjFvw8+QsTwaibxSsmDSx6wy7JkK81wPZ9m2LmuxbjCVo4TyhGFHWx2PyPozajCmBd0AGr39JwjWWuOYIFQ9CP1hMZHsIks0rx57ipyyV0jlxqPje9U9O6yO54Kb4aX2tDSuX5/dc9dzRT/sPMeiMwQ37uFsehgvSnFKBtE+aLxuCmwxZcNLywo0Di1VXarbm/BEiRTMeNvTIDR92SQBgulrkwg==
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=T0pPts9tuxFM6gtNEZMAYk2INp+9Ft5ZnL5CmnwiWa0=; b=E65sMx2XbzW2bvLdYoZePGKoH8NyT+coL33viu9T1zQNrAOIIruwwfyjwysP24wuiKk2XMsuQlNFh6YFLcVwIK0yVc6sjSvuNgbJI6XcNyF4gADXk0goeU+Arrtifx3BTbZWH4M1+yvV9TTXbmi8QsdJjcAIrVGg4PWl1E193xg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Fri, 30 Aug 2019 11:44:26 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 11:44:26 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Martine Lenders <m.lenders@fu-berlin.de>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB
Thread-Index: AQHVXxckGX8iRyyyNUODZAbfHFSG36cTiwwA
Date: Fri, 30 Aug 2019 11:44:02 +0000
Deferred-Delivery: Fri, 30 Aug 2019 11:43:21 +0000
Message-ID: <MN2PR11MB35658D8325E730B3FD593019D8BD0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CALHmdRxLUXy9g94iYn+7Ujmr+0bmBR0Oo3psbHcZOauT08rOHg@mail.gmail.com>
In-Reply-To: <CALHmdRxLUXy9g94iYn+7Ujmr+0bmBR0Oo3psbHcZOauT08rOHg@mail.gmail.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:c0c0:1003::52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ad56cb67-a4da-4241-939d-08d72d3f690a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3695;
x-ms-traffictypediagnostic: MN2PR11MB3695:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB36956A22475425754CC66EF8D8BD0@MN2PR11MB3695.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0145758B1D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(346002)(396003)(376002)(189003)(199004)(476003)(229853002)(11346002)(76176011)(99286004)(52536014)(5660300002)(2501003)(86362001)(7736002)(256004)(486006)(6666004)(6246003)(316002)(478600001)(2906002)(14454004)(53936002)(8936002)(790700001)(6116002)(6506007)(606006)(81156014)(81166006)(55016002)(236005)(8676002)(6306002)(25786009)(54896002)(71190400001)(446003)(74316002)(110136005)(7696005)(33656002)(46003)(71200400001)(66476007)(186003)(66556008)(66946007)(6436002)(76116006)(9686003)(66446008)(64756008)(102836004)(79990200002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3695; 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-message-info: nczw6mP0EphW7j2kgMZtSIj45zNUIP+yhDMJCL7dUs6zpZHceXfqFS8dp6hDVYGQxdaR6HRC34GeEle9ib1dURmSMGIMMftxSVfzYgYp06egHvsCbbTdxI5DgN2fJyLEBpSFca8lFx2IXDerxSKP0bYdmlsJ0Av+Eh9H9rA/oMdSHEHi0bebUW0x8zK1mkD8LjdkYNWQWiXX5qMN+zaP0bnEfYQ0d2ztTuE3wLKW+anGaQj5uLiJFpSqZCDSCq5LhNAgNM8OPznt0zAMKyYewJIp9KtoXY82WJNFSTMqbUg7IlIWLFkGKZ5WdDTBA48Mv4BbQx9g2rlyfoC0QLF958DJ+EQJUU0XOEGF/9w124y94JGPxlsKcMoqkUoS9GDkV4qjMAqbj6a0Rf3dpe7oxLZoPz6rsYJEefvkbeOl1cpIzNJoyUs/f/t+hqYBZ4zGnjSN+zrssOs4vpG1mcgkrQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35658D8325E730B3FD593019D8BD0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ad56cb67-a4da-4241-939d-08d72d3f690a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 11:44:26.3645 (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: bL7QIl7ijHfGMCtjrdIJe112Aevi5XKPEnnkh/KfgjGxlIr3MnIbp1P6wAK561q7bDNjnA4TX7/uik7jCWDGIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3695
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/4KDmElE8hPv8s5eBi3aiLrryndg>
Subject: Re: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB
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, 30 Aug 2019 11:44:34 -0000

Hello Martine

Great to hear about your implementation. The group is interested to learn about your progress (keep us tuned) and happy to help you through. P
lease do not hesitate to ask for more clarification as you feel needed. Even if you’re not too sure you should ask, if you wonder there’s probably a reason and you’re helping the implementors who will be following you.

Please see below:

I have an implementation question for the virtual reassembly buffer with regards to [draft-ietf-6lo-fragment-recovery]. Section 6.1 of this draft states that a tuple (source address, tag) is used to identify a VRB entry and cites [draft-ietf-6lo-minimal-fragment] for that.

Ø    Correct, and the meaning is source MAC address not source IP address. The exact sentence is

Ø                                       Upon a first fragment (i.e. with a

Ø     sequence of zero), a VRB and the associated LSP state are created for

Ø     the tuple (source MAC address, datagram_tag) and the fragment is

Ø     forwarded along the IPv6 route that matches the destination IPv6

Ø     address in the IPv6 header as prescribed by

Ø     [I-D.ietf-6lo-minimal-fragment<https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05#ref-I-D.ietf-6lo-minimal-fragment>;].

Ø
However, as far as I understand [draft-ietf-6lo-minimal-fragment] and [draft-ietf-lwig-6lowpan-virtual-reassembly] this is not the case. [draft-ietf-6lo-minimal-fragment] doesn't mention VRB entry identification and only refers to [draft-ietf-lwig-6lowpan-virtual-reassembly].

  *   It would not hurt to mention it though. Interesting. Minimal has:” All fragments are tagged with a 16-bit

   "    Each datagram can be uniquely identified by the source and final

   destination link-layer addresses of the frame that carries it, the

   fragment size and the datagram_tag.



Ø    That’s  misleading… I’ll correct it.
That in turn only recounts the classic (source address, destination address, size, tag) tuple defined in RFC4944

  *   When receiving a fragment, the destination is self and the size may vary from a datagram to the next. So the only thing that really identify the datagram is the source MAC and the tag.
and states that the only difference between the classic and VRB is the lack of the reassembled packet and addition of the next hop's address and the newly assigned tag:

Ø    Actually the forwarder sends the datagram with self as source to the source mac address is swapped naturally. It has to set the next hop’s mac address and the swapped datagram tag. The next hop’s MAC address identifies the node that should receive the packet and the datagram tag together with the source mac identify the reassembly buffer within the receiver. There is no contradiction.
To reduce the memory requirement for reassembly buffers, the implementation may opt to not keep the actual packet data in the reassembly buffer. Instead, it may attempt to send out the data for a fragment in the form of a forwarded fragment, as soon as all necessary information for that is available. Obviously, all fragments need to be sent with the same outgoing address (otherwise a full reassembly implementation would discard the fragments) and the same datagram_tag.

So my question is: Is the tuple definition in [draft-ietf-6lo-fragment-recovery] really correct?


  *   It is.

For exclusion datagram size I agree that it could be somewhat redundant. However, a node could have multiple destination addresses (either via multiple interfaces or IEEE-802.15.4-style short and long address). So, as the tag is link-specific (defined by a (source, destination) tuple), there could be distinct datagrams that have the same tuple (source, tag), or am I missing something?


Ø    Yes, the role of the destination MAC address is to reach the next hop, but does not change the processing within that node. I could change the L2 address I use to refer to the next hop in the middle of a fragmented packet, it is still the same fragmented packet. In other words, please do not use the dmac as to index the VRB. From your question I think the LWIG draft should clarify, and we can change minimal draft to clarify as well.

I already implemented the VRB with draft-ietf-6lo-minimal-fragment in mind and thus used the classic 4-tuple for indexing. But now I'm wondering: Can I reduce its index or would that be not advised?


Ø    You should reduce the index : ) There can not be 2 different datagrams coming in parallel from a same previous hop and with a same datagram tag. There must be a sentence somewhere in the LWIG draft that says that a new and currently unused datagram tag is chosen for a new incoming datagram, correct?  Minimal says

Ø                                                                Upon

Ø     receiving a fragment from node A with a datagram_tag previously

Ø     unseen from node A, node B allocates a buffer large enough to hold

Ø     the entire packet.



Ø    This text only indexes the VRB with any identifier of node A and the tag… And this is correct. What’s a bit more ugly is that Node A should not change the source MAC in between fragments because that will confise node B. I need to add text on that too.


Many thanks Martine for raising all this, and all the best for your implementation.

Pascal