Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 September 2020 12:55 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE313A0BC2; Fri, 4 Sep 2020 05:55:09 -0700 (PDT)
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=gopX1oAC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZrVFcXX8
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_io5BR01HBO; Fri, 4 Sep 2020 05:55:07 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65213A09E8; Fri, 4 Sep 2020 05:55:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8190; q=dns/txt; s=iport; t=1599224106; x=1600433706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A50kkR6ZeerdMpVIjVw2hnSRz/yOdwnXb2x2a6VwzFs=; b=gopX1oACyY/O8ArjlHN/AtUcn+giRjaXkC6fIP/F9VSM0UepSqsIO86A gG97hoUUa3zseD2wrvAnIP7oPFpailnTCNGUEBDGJ6KGmRYU9BenXdWnG QHn7s7IdGtRt6rQbwwDvUE3TwGLv/Xawj7DGn+P1irlIO2vQpEXHwHe94 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3AjAQzlxGEDuvlzYa0+VFVj51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsEADJOFJf/5hdJa1fHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFMgVBRB3BYLyyEOINGA412mHGBQoERA1ULAQEBDAEBGAsKAgQBAYR?= =?us-ascii?q?LAheCHgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAwEBEBERDAEBLAs?= =?us-ascii?q?BCwQCAQgRBAEBAwImAgICJQsVCAgCBAENBQgagwWCSwMuAQ6mVgKBOYhhdoE?= =?us-ascii?q?ygwEBAQWFBhiCEAMGgQ4qAYJwglpLQoZQG4FBP4ERQ4JNPoJcAQEDgR4WKoM?= =?us-ascii?q?VM4ItkxuiU4EACoJliGiGUIsbgwmJb5NekWRtik6QYYQoAgQCBAUCDgEBBYF?= =?us-ascii?q?rI4FXcBU7gmlQFwINjigag06FFIVCdDcCBgEJAQEDCXyNSYJFAQE?=
X-IronPort-AV: E=Sophos;i="5.76,389,1592870400"; d="scan'208";a="549340383"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Sep 2020 12:55:05 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 084Ct3wn012043 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Sep 2020 12:55:05 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 4 Sep 2020 07:55:03 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 4 Sep 2020 07:55:02 -0500
Received: from NAM02-BL2-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.1497.2 via Frontend Transport; Fri, 4 Sep 2020 07:55:02 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f+k9QUqN+lvOW3PQGdFwHD1yFVx/wL6JUyU/1RvKgt3T1uVTZ5AKwiHXPImI5ZuC76Vc5tZEQ6qTXT8zCt/zGbP4xxLtcW4exaHz0XD827opecQW3V+PlwwALhVMwsjUb6n1QjNUF8j0AaXxoUN9qlSOUqTpDJAGVmDAxLWT4JRUL8odwIbCfT5FWU+UeiTPQEy1clZXts3Dj5jZdSosAQS8RML1E3cXYraEHPBpuTkz+ITwEeFBs6PGi8TGKb6kwRSTsoH+JuJkIF9UsmsUhES68GHO9dJ5tC6EsblHNBE9lpnuj9XXsT8Ywvvr4fcagDtR0wEqABYYnJj37FDvCQ==
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=A50kkR6ZeerdMpVIjVw2hnSRz/yOdwnXb2x2a6VwzFs=; b=Qs+bDjkJ5igXmW6GXpJTW6Zm6xNfrFZzY5IVIpt4bm3UH9QkD6dYMoT1MjA6yv+SOZIGy7wNmD1PkyhzPd08uHDRkzXRcTH9+3AjQ36QkWkeM/iqqPqdXAy0sBzuIIgk/+Fz6DnZbp3Hju7de3TxJkGN3gIzLEXjrujPADygas+BK8cFLyPHKP9DUzv7usVCxDhs+ELtq565qnbzdZ9R9MvvH64hqDoIkEc7I9h7At6ehhxaBvTqTIKjPbKMbNRXp2BRFaEq+3uVP4mLvxYkP00BBjT3tXh8h14xhT1VFp/2k+MYtulxIUfSAR6I7rdGK+Y0Cvk3psUWWpx6nuzGYQ==
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=A50kkR6ZeerdMpVIjVw2hnSRz/yOdwnXb2x2a6VwzFs=; b=ZrVFcXX8gU4itELDir1nYDwAQbK8Gxios8qEYZLkLAhIr06B0hmAUrsL9MFX16rD95DyXOSzDUdhdCaXCrrtn4i1DQG8hacZQ6dBUa1e1Qs4avOXyQk8slBffZw7ZWkIN3GFMy9VTFOEDEF3sPu6rBGJxWYis7giFE5oYzMpcvA=
Received: from BYAPR11MB3558.namprd11.prod.outlook.com (2603:10b6:a03:b3::11) by BYAPR11MB2838.namprd11.prod.outlook.com (2603:10b6:a02:cc::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Fri, 4 Sep 2020 12:55:01 +0000
Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::1835:beb0:16e1:e860]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::1835:beb0:16e1:e860%4]) with mapi id 15.20.3348.017; Fri, 4 Sep 2020 12:55:01 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-roll-useofrplinfo.all@ietf.org" <draft-ietf-roll-useofrplinfo.all@ietf.org>
Thread-Topic: Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
Thread-Index: AQHWZatpIbCVz7UqIkiC9q5PoH5DKKkfs90wgDj07DA=
Date: Fri, 4 Sep 2020 12:54:50 +0000
Deferred-Delivery: Fri, 4 Sep 2020 12:53:52 +0000
Message-ID: <BYAPR11MB35586BE933AD0D79A4B07038D82D0@BYAPR11MB3558.namprd11.prod.outlook.com>
References: <159602896040.32219.18351168129491497436@ietfa.amsl.com> <MN2PR11MB35652FAB1C566C880EC77A04D8710@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35652FAB1C566C880EC77A04D8710@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:e113:dd97:15c5:93ed]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3591ccd5-4f93-42e4-f416-08d850d1bc96
x-ms-traffictypediagnostic: BYAPR11MB2838:
x-microsoft-antispam-prvs: <BYAPR11MB28380D45BA0BEBC9AAC797A1D82D0@BYAPR11MB2838.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GFVeVpWrpbwC77zOz6JWvvOJdPEr0k/xWFKMRJVAA7oK/gI7GldJdDw+XTS/VZH+pzDgVDxZ23IkeliAtA4jlnP8mB2hh666YHWLYn9/PYXxYPf+s8m1BwLVwNDOonNhqhKtkAHRT758Pd0tDogwy9FCV7Th19THfwCzNwASO48VEnuA0h32V/AfNI0mghyRYGOKiuWE4WN019ZjRtQSeQVGBvQQcL9Dnuqv/vW6DHy4PdqfKweRh/jd6umhQrq+KKAGOaHtlu8mSCGhqJ5TLalR3SZMtP09b3qWhVSyZ0hp8wzKgdvzjNM2z2K6iaJrKNavVaiO3dBiyo3krLgRyeGMkjduRVUpJUU+sOZIXusTmIy3VvqPLzwxMOMst8PT7iuBrUhKQhkKV0tjZL+CPA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3558.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(366004)(346002)(376002)(39860400002)(55016002)(7696005)(6506007)(53546011)(110136005)(9686003)(54906003)(8936002)(83380400001)(966005)(86362001)(66574015)(316002)(186003)(5660300002)(76116006)(478600001)(71200400001)(66946007)(66556008)(66446008)(64756008)(66476007)(33656002)(2906002)(8676002)(52536014)(6666004)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: kT2UVZXR76nR4IlPaiUY1Vm9DDozbDEaaQIvDM17n2zfFzpyja/msKojCkzTS1zKedihX7/AaMGmrz2odMjWoDkG/McL58BUpus5+QwzyfoG59fZcP3enR2xpFQRpWmQa2/Kq9zJ/29cxynqMmWHEccTk1smvci0GNjKExzVssP0iH3R9pQh8b+1BuD2p7eO2lbqf3MJkdjkPhMtkENLqoCzf9LMVA9WypqRtIi4tkZ4nUE9O1N/rCUV/Q4Q/XRBjD/rcMcMIWDuLxRRao16LZ1cTeBJAMB9duXhCx2uzSPwQmZMTrXJky3G+xz1A75Xyr/NtTdLC+veQI2NAOkxHPyQnBBXGwrObDs3iOBbZb6fVddHydC4/eeE7Bd1iMjLyLM0El3DFNXh4GDJFr63InSvg1vPOG3iDdrEwaYzwLY5im+vkJ98U/DknqN49/Tw6hhq/SxgS8b5rfK1XEE5Z+fvpnihmzCu8Ho26C91vAMyJtWM8SnQ/bn6HA4jVfySfK9PChQVTPMUOLq4kAJlya7Q/DQutIdmfF9iIqBKPlbL8BOWpGEeQoE8cnGNqSLuM3qHBmpb/LGZQoRNB6ipIGnNoCBUHILm1e/X1SypB3tBOVQI8YjlTl7I+aCBgvRCYmekjQYeaEzQ2T5l5t3vKf8ZvpibXMwHLuHXrp7PPoMfaEA1vPKzD8qA3g5eB3ds2gABvvvmDQK6ACoNS0uZ9g==
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3558.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3591ccd5-4f93-42e4-f416-08d850d1bc96
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 12:55:01.3842 (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: nF3T5Uod40uy3ka5OpWs+vHtq8ajzJdZseNdvSNuQTihzDNGQFb/1nk4hmdvpsOAWqvOwVRFfVGIk4gcNsKMnQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2838
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/C-vIQz-03LeWqlIu1ZbKvuh5fAI>
Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2020 12:55:09 -0000

Hello Malisa

I rechecked RFC 6553. It is contradicting itself somehow. Section 2 has a lowercase must for the RPI. 
Later RFC 6553 says “  Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([RFC6554]) and MAY include both.“ RFC 8138 requires the RPI at all times for compression. Now we MUST the RPI in all cases, it appears simpler to be able to count on it to apply QoS.

Take care,

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
> Sent: jeudi 30 juillet 2020 11:08
> To: Mališa Vučinić <malisa.vucinic@inria.fr>fr>; iot-directorate@ietf.org
> Cc: last-call@ietf.org; roll@ietf.org; draft-ietf-roll-useofrplinfo.all@ietf.org
> Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-useofrplinfo-40
> 
> Hello Mališa
> 
> Many thanks for your review!
> 
> I'm not the editor but I'd like to refine some points here
> 
> >
> > Section 1:
> >
> > > Since some of the uses cases here described, use IPv6-in-IPv6
> encapsulation.
> > It MUST take in consideration, when encapsulation is applied, the
> > RFC6040 [RFC6040], which defines how the explicit congestion
> > notification (ECN) field of the IP header should be constructed on
> > entry to and exit from any
> > IPV6-in-IPV6 tunnel. - Please clarify the sentence. Consider whether
> > it is appropriate to have a normative MUST here.
> 
> That's a good point, but then all the best practice of encaps also applies, not
> sure we need/want to list them all.
> I'm afraid that if we start listing some we miss others and get in an endless
> discussion at IESG, e.g., fragmentation.
> 
> The reverse angle could be the MTU discussion.
> If we use RFC 8138 then the IP in IP does not really steal from the 6LoWPAN
> MTU of 1280.
> If not it does. So on paper the IP in IP encapsulator should fragment at the IP
> layer. This might happen in particular in non-storing mode with a routing
> header that causes a larger encapsulation.
> But as it goes, even though the MTU is 1280, the fragmentation allows more
> (2048 with RFC 4944, no explicit limit with https://tools.ietf.org/html/draft-
> ietf-6lo-fragment-recovery-21).
> 
> So it could be good to add text that says:
> - best practice IPv6 encapsulation applies
> 	- mention RFC6040
> - there are exception
> 	- no IP layer MTU discovery (because MTU is 1280)
> 	- though MTU is 1280, no IP layer fragmentation when the
> encapsulated packet is over that (because fragmentation copes with it above
> 1280)
> 	- The recomposition buffer SHOULD be large enough. We could
> RECOMMEND 2048 bytes.
> 
> 
> > Section 4.2:
> > > The non-storing mode case does not require the type change from 0x63
> > > to 0x23,
> > as the root can always create the right packet.  The type change does
> > not adversely affect the non-storing case. - It is not clear what RPI
> > option type should non-storing networks use. A pointer to the
> > discussion in Section 4.3 would be useful.
> >
> 
> Note that adding/removing an RPI on the way (e.g., at the root) always
> involves en/decapsulations (ask 6MAN!).
> I'm not clear what difference you make there?
> 
> The problem is for packets from the LLN node to the internet. This is the same
> for storing and non-storing.
> 0x23 allows us to not remove The RPI thus to not encapsulate at the LLN node.
> Maybe that can be clarified.
> 
> We deprecate 0x63 globally and want it replaced by 0x23 in all cases. Maybe
> that can be clarified too.
> 
> 
> > Section 4.4:
> >
> > > A node that is decompressing this header MUST decompress using the
> > > RPI Option
> > Type that is currently active: that is, a choice between 0x23 (new)
> > and 0x63 (old). The node will know which to use based upon the
> > presence of the flag in the DODAG Configuration option defined in
> > Section 4.3. E.g.  If the network is in 0x23 mode (by DIO option),
> > then it should be decompressed to 0x23. - If my understanding is
> > correct, this means that in order to decompress data plane packets, a
> > node first needs to remember the option type mode the network is
> > operating in, advertised in DIOs. Consequently, decompression is not possible
> before at least one DIO is received.
> 
> True. At that point the node does not even know it is in a RPL network.
> Note that the decompression generally happens at the destination of the outer
> header which removes the RPI if it is a router and ignores it if it is the final
> destination. So it does not really matter.
> But just in case we can mention that the default is 0x23.
> 
> 
> > Section 6:
> >
> > > The RPI MUST be present in every single RPL data packet.
> > - How is the normative text here appropriate at this point? Is this
> > not redundant with RFC6553?
> 
> Agreed to lowercase it, and as you point out all the uppercase which echo an
> existing RFC
> 
> > Section 8:
> >
> > > The root always have to encapuslate on the way down
> > - It is not clear how come does root need to always encapsulate on the
> > way down. In the basic case of root to RAL communication, IPv6-in-IPv6
> > is marked as “No”. Please clarify.
> 
> Need to clarify that this is for routed traffic not self-generated traffic
> 
> > Section 8.2.1:
> >
> > - A sentence stating how does RAL recognize that the packet is
> > destined for the Internet would be useful.
> 
> Note that that it does not need to. With this spec, the RAL may do the same
> thing whether the destination is a RAL, a RUL, or the Internet.
> But yes I agree; we could say that if the RAL knows what the RPL domain is, it
> may encapsulate to the root when the destination is not in that domain.
> 
> 
> Many thanks again!
> 
> Take care
> 
> Pascal
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll