[Roll] signaling RPI option value and support of RFC 8138 in RPLv2
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 12 December 2019 09:36 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 1141312087E for <roll@ietfa.amsl.com>; Thu, 12 Dec 2019 01:36:15 -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=hrrBB9mn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qT1qJn8G
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 y-0Yyi1RuYJK for <roll@ietfa.amsl.com>; Thu, 12 Dec 2019 01:36:13 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0555812087C for <roll@ietf.org>; Thu, 12 Dec 2019 01:36:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2030; q=dns/txt; s=iport; t=1576143372; x=1577352972; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UnxVXKbnTWl7dtpjoxxK1TwXkvhezCrYPC9rKZpPP1I=; b=hrrBB9mnSMJ5qnKPdkGBGP62yFIiF8QnuKVVVhaqrxq5VI5RoY3TIZNm +6CbAocLTqoc26l3UDB+j/uhSdgkd48xqUUvJ6Ki72kq/ExHnZn0NfVus C9ovew0gPh0/DDHnrOjHmFIjnSAY6/rNyKZZU01cXhJIoRgvj6oLs7/xU k=;
IronPort-PHdr: 9a23:LXYlLBHpIv12jvTUPalemZ1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9DwC6CPJd/5pdJa1lhA9QBYFEIAQLKodJA4sJTpoXglIDVAkBAQEMAQEtAgEBhEACggokOBMCAw0BAQQBAQECAQUEbYU3DIV3LgEBOBEBgQAmAQQbGoVHAy4BAqIMAoE4iGGCJ4J+AQEFhQcYghcJgTaMGBqBQT+BEUeEDoNHg0CCLJcGl20KgjCWFJpBqQgCBAIEBQIOAQEFgWkigVhwFYMnUBEUlBOKU3SBKI59AQE
X-IronPort-AV: E=Sophos;i="5.69,305,1571702400"; d="scan'208";a="685614712"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Dec 2019 09:36:11 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBC9aBfX005852 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 12 Dec 2019 09:36:11 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Dec 2019 03:36:11 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Dec 2019 03:36:10 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Dec 2019 03:36:10 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iqlNsblsFoKaYKjzjUSL491d4iFDbXyJu0XiTdXOa37vTz7QCPqdejMH7BQ+V8M+oWKnL88+eShIpy4Tj8IXRu39n0cbi5Sp1AGdQQvzdu8LXSYfv6fNTPAZqQsfewHAHnsFXS+KwI6EDrEKrKCQf4BN54XYzxVv0xQkxeJKFGzxw9I80Yq58wjAkUotFvtHaxTXJRHboyyyp69hY293GM+4hlwzeEXzD8OgVCOd5lCRanLvXNGeHDvhTJjOmZEUZWeE9mpAGFO5pFP8fLmMQgKmRBrHBmGnPdjBjQjYL8Gs7klvg3fPxjuzcieZrIzCUAIR9q6vCrMcTMPe5Z9Mag==
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=UnxVXKbnTWl7dtpjoxxK1TwXkvhezCrYPC9rKZpPP1I=; b=BkPdHNHOQQXPLH0mpqlVLI4N4PafXrX9VODp4m+1DweqLtS8yzPDDdllwH+6IEXc62+sWLsH2FGQVf44RpSNNj1NzUNXBxyFVOOYwe2hhN4t9y0mXPs/ekJpyZWJC5IMPWGw/DDagh1LinRWlh3ZpfSPxLdeX819tg/yCFyd9SXcmPbMcZfM39e7+F8wfA82Szhe00xD6ih70XLjnSls6nhGhAQ5mQ2LXPWPDst/Hdf4E1F23XdtovstLEA6hNksbaNYZt6Y5JWwZdqRNgCM+cgoI7hgDatqAviL947h3RZ3Eu5xw8PpemMCF4oHuT1c/DaGG70FfdX1UiNlQhEg8A==
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=UnxVXKbnTWl7dtpjoxxK1TwXkvhezCrYPC9rKZpPP1I=; b=qT1qJn8GJNdBeMgER0clVXDBPQ9KoFSXiOnnNM9Fk21Sm52PA7ee6BuY9u8dba91YUot2oXEaSjrPBnEvjMdKcwxSSrlH50PYnjrLjJ5KC9elcwwtuoCNA1Mr/F13PujAbdIYwPrGydIgg9oF7Bj+EXcgIm5aAdZAz+euEIfLDc=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4125.namprd11.prod.outlook.com (10.255.181.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Thu, 12 Dec 2019 09:36:08 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564%7]) with mapi id 15.20.2538.016; Thu, 12 Dec 2019 09:36:08 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: signaling RPI option value and support of RFC 8138 in RPLv2
Thread-Index: AdWwzn7gMgNzwlXdRRC+R0XCHIl1+w==
Date: Thu, 12 Dec 2019 09:35:45 +0000
Deferred-Delivery: Thu, 12 Dec 2019 09:35:01 +0000
Message-ID: <MN2PR11MB356594C2F7955220956FF6B0D8550@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: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4df:6600:3cca:13de:1f:eca8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5bf95f59-89e5-4693-985c-08d77ee6b793
x-ms-traffictypediagnostic: MN2PR11MB4125:
x-microsoft-antispam-prvs: <MN2PR11MB4125E2C67C3449BB7C63E928D8550@MN2PR11MB4125.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0249EFCB0B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(136003)(346002)(199004)(189003)(76116006)(33656002)(8676002)(81166006)(86362001)(81156014)(186003)(316002)(6916009)(66946007)(66476007)(478600001)(66556008)(2906002)(64756008)(5660300002)(66446008)(52536014)(6506007)(9686003)(55016002)(7696005)(71200400001)(8936002)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4125; 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: aUstJjk8k8wcEox/UyizyoqzQ8d64RmpciSxG70X8rjRyrZFnvifEp1hssMyKzPiN2tJ4cLWcwixvOk15/sRtA2OKMdlBLCmVnW6Z4PabQlUJrCYwhcEro8gj2vsgLT5CqCSSo5jmD60hkFjRLWOFQBVBV8M1uRUPkKQVk1U/Xvhi0NlZvfew/Mw2ArJVC7hfN30iqbnQ7bOaMtHHyAVlZOnMcCABfZfyt1A9+Tr1J7c4FOZABczc9iuG6c10W1IAwOH9L4ALZLh72RFpBejSpm7vXboqgcO90asz4ZNcf3Byk1vOw1f4/99dY6ftWUf7zImTezuKBSARyDzkf/MnMDod0+wED9jR84jQFbFlArK+szWFYwGfDfKsn5DJm39dbS9ZYzzB0TCpVnYabbks/9Rb9ZavuJ/H55zWRXQWOUunBqaMh5uyjNsZ6DX6lpw
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bf95f59-89e5-4693-985c-08d77ee6b793
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2019 09:36:08.1536 (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: QHe88fedL77rdvhIh12G4rJXiuw4otrTrOSJaW4o7sA8EgI85Hh3dzGJCpjbqfjtFRhgHjttbC3eOG4BdoeLrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4125
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/OgMJNnkPzFn_kxcjFcpwbMMtg_E>
Subject: [Roll] signaling RPI option value and support of RFC 8138 in RPLv2
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: Thu, 12 Dec 2019 09:36:15 -0000
> [Rahul asked] I would like to confirm a point here... Reclaiming the turnon-8138 flag in MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above MOP>=7 such that they no more depend on this flag. This in itself is a bigger decision! Is my understanding correct? While the advantages of 8138 are obvious in non-storing MOP case, they are less impacting/obvious in storing MOP case. The configuration bits can be reclaimed if the value is always-on or always off for a new MOP. When defining a MOP, it is possible to indicate either way and then to reclaim the bits. I see that MOPext could say, individually for each bit: a) For any MOP >= 7, the bit is implicitly always on (or off) unless the MOP specification says otherwise b) For any MOP >= 7, the MOP specification MUST either indicate that the bit is used as for MOP<7 or provide an implicit setting c) For any MOP >= 7, the bit is implicitly as for MOP<7 unless the MOP specification says otherwise My preference goes to a), defaulting both settings to on. My rationale is this: . A default value simplifies the writing of the MOP specs. . For the RPI option type, we deprecated the value 0x63 and RPLv2 seems like a good flag day. I expect that no MOP > 7 will ever turn it back on. But if we were wrong doing this, then a MOPext bis can always reverse the default above another step of MOP. . For the RFC 8138 turnon bit, even in storing mode, there's IP in IP for packets coming from the outside to insert a HbH header, and compressing those 2 is already a huge saving. I'd also argue that all known implementations for constrained environments support non-storing, so the code should be there. I'm not sure it's a huge footprint in the devices, considering the value in each packet, it's certainly worth it. Finally, the nex RPL signaling (P DAO and RUL) already uses RFC 8138 to compress the RPL control packets. What do other think? Pascal
- [Roll] signaling RPI option value and support of … Pascal Thubert (pthubert)
- Re: [Roll] signaling RPI option value and support… Michael Richardson
- Re: [Roll] signaling RPI option value and support… Abdussalam Baryun