[Roll] RPI Option Type in useofrplinfo

Rahul Jadhav <nyrahul@outlook.com> Thu, 12 March 2020 09:04 UTC

Return-Path: <nyrahul@outlook.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 38A703A13C6 for <roll@ietfa.amsl.com>; Thu, 12 Mar 2020 02:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 vmE2FN2rDcVZ for <roll@ietfa.amsl.com>; Thu, 12 Mar 2020 02:04:23 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255032.outbound.protection.outlook.com [40.92.255.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236283A13C1 for <roll@ietf.org>; Thu, 12 Mar 2020 02:04:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DY9CA0Q2n0TbJPa7QfocVbosb+5CQXSXcgqdpz/K1utzy2dZy7SbsD5wd63Dz+?= =?utf-8?q?Be9KxcYjY4ptsY8LroMx/ProfaHJq2ssqIlcE5+WLGggSmGFkazSG48CosjKJdN7p?= =?utf-8?q?olTMNEr9gOQwojGWvdD6jrBZe+Tv5KzPR2xUwcFQfQVTvB5pL2di5EVqPfhm173qf?= =?utf-8?q?GxTGghm5QpZL55cZEO4GHBb79M+EUyX76Dls6K2fxBfx5gZ0udkzrPQjt5j3jl1aT?= =?utf-8?q?LmN3FJ7Yel+Px+30yekNXlP8GUwP5Ta+7wNtnZFxkmYUlOUqPT1E89SqmtXsjWmrg?= =?utf-8?q?1aKoB6u6Wcce2CL6kp4FA=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=3DCc0uUAmSzVGJ4GAfWa/tSnlremUay0qyK4lpiIMXgdA=3D=3B_b=3DWzTNZY?= =?utf-8?q?J0rDHtapwWmkg/xeBYOTWGdF2DvMtog9q96m9OHMOi2jMucmjGcArdUtfeehYPl/g?= =?utf-8?q?bZvGa4a1kRGsEcYO/6GPQeAlIWPxYwMCT94fTs5ZgxsDXWkyNXphwkaP+XivTK9IA?= =?utf-8?q?sgeyvH02v84hqC0RV2wkmUpo7SArl4iGiKWTrI8bguMlTAuEjGsEhhSpVKRjsF9iR?= =?utf-8?q?yDh6xPtWM//ixkUWf/8j6zXD9fOre5mufspuTxTxPJdmXFdYo3A59wKfDalez4tr1?= =?utf-8?q?MviqVm/e660h/3VsIc7xEcF6Q1ZN0UmaD5L44ExgiJYtG3+R/tlkNRXA9rYYKwTjk?= =?utf-8?q?HHxcT2nl/ZQ=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DCc0uUAmSzVGJ4GAfWa/tSnlremUay0qyK4lpiIMXgdA=3D=3B_b=3DTUNBIK?= =?utf-8?q?y6K928GOvCuhxVlTJEF+tpFdfN8GP54arhx4kILK9txcWE4SMcf3upsqQo0IMlR/X?= =?utf-8?q?gCksm0beylkuNptVRMiGSLwcGT07d95VvpqJG5saJDT7MKCLde+/hCqaE1E487Ogq?= =?utf-8?q?YrAHPn4fYj0qbQD/sFDMQ7PTTWqI13rh+tRjN7ueZ2AXdJt5AaqO/87u8NjAKepdH?= =?utf-8?q?4V37+2dh5LJo4A6wUf5+8VQBQcUdKqT6G3nBF6Xp59x+dEN/Nuov3VK5yoQ83FZrm?= =?utf-8?q?75Wv23OVnLLSK2GQOHcrWJXzootlJeZCfbIhXaRx42TU/hYzFAj0dQqCbhG3Pky8H?= =?utf-8?q?zWGzUhNFvRA=3D=3D?=
Received: from HK2APC01FT014.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::3c) by HK2APC01HT153.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::468) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Thu, 12 Mar 2020 09:04:20 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.248.55) by HK2APC01FT014.mail.protection.outlook.com (10.152.248.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Thu, 12 Mar 2020 09:04:20 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050%6]) with mapi id 15.20.2793.013; Thu, 12 Mar 2020 09:04:20 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: RPI Option Type in useofrplinfo
Thread-Index: AQHV+EeGEJooQrZVX0uiNICkr0YrUw==
Date: Thu, 12 Mar 2020 09:04:20 +0000
Message-ID: =?utf-8?q?=3CBM1PR01MB4020DDE62CBD04217E48C180A9FD0=40BM1PR01MB4?= =?utf-8?q?020=2EINDPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
Accept-Language: en-IN, en-US
Content-Language: en-IN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: =?utf-8?q?OriginalChecksum=3A89C5067822D4C8E1522D?= =?utf-8?q?B43BDECCB1474DE2B0A830951334854E8D57C12A3F62=3B_UpperCasedChecksu?= =?utf-8?q?m=3A1CB4425C1008E3C7068D675BE259C630F97AC363119755709F8D2D13E660D?= =?utf-8?q?648=3B?= SizeAsReceived:6661; Count:42
x-tmn: [ggI+ptURrTKKPB8MH+8PKPUrcgeqz0bM]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d3726853-cca6-4bc3-1956-08d7c6645a20
x-ms-traffictypediagnostic: HK2APC01HT153:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?3C2JZBGmy1amA0oyVrlu66KiuqRhQOZ?= =?utf-8?q?zLBSb5GSay23bLmP+ts9Ecp8eho/dAqna9SMpMBmGHE650csmizvTTmu3cDiG39oj?= =?utf-8?q?J1O4xbKzMFrf1n5+kF92X+4Fzj9JDWkvDMgb+e4W3mBsSOX1LWPCNdggfLZecW15b?= =?utf-8?q?HKTmi+NcUBww8ZcIgpybFB8OfeSUcoj?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?9GkMUYBlH6s0LF4y3mmH5K2C2NjXkl?= =?utf-8?q?pgdtcfRk7NUl3GMCIYO/LIkJwDs3i6cm9YyDgiV+VLSnAWJaRrRBqq28w0tKv6qvl?= =?utf-8?q?y5tT7Nbqnvu6YLCi2nBndP7aUAnEA12kBw+gfSNOlbE91o8ybHoaK3Q=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020DDE62CBD04217E48C180A9FD0BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d3726853-cca6-4bc3-1956-08d7c6645a20
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 09:04:20.6847 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT153
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/aXCvBg7BsYYNEKMhsyFRqs6A97c>
Subject: [Roll] RPI Option Type in useofrplinfo
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 Mar 2020 09:04:25 -0000

While reading section related to RPI Option Type, I had some doubts:

Section 4.3 states,
"In the case of rebooting, the node (6LN or 6LR) does not remember the
RPL Option Type (i.e., whether or not the flag is set), so DIO
messages sent by the node would be sent with the flag unset until a
DIO message is received with the flag set, indicating the new RPI
value. The node will use the value 0x23 if it supports this feature."

[RJ] A node can initiate a DIO only when it decides to attach itself to the Instance/DAG based on DIO received from the upstream node. Thus a 6LR/6LN __will always have a ref value to use from its parent's DIO__. The para states, ".... so DIO messages sent by the node would be sent with the flag unset until a DIO message is received with the flag set.....". This may be incorrect because the node will always have a flag ref from config option from DIO rcvd from upstream node.
Subsequently, in the same para, the text says, "The node will use the value 0x23 if it supports this feature." Do you mean even if the flag in Config option is not set it can use 0x23 if it supports the feature? This doesn't seem right! Contradicts with other stmts in the same section for e.g., "Thus, when a node join to a network will know which value to use."
>From my point of view, this para is not needed since there is no impact on 6LR/6LN for this flag because of the reboot operation.

Regarding the terminology: The draft terms, the new option type as "RPI Option Type" (value 0x23) and the old "RPL Option Type" (value 0x63). Is this correct?

Thanks,
Rahul