Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

Rahul Jadhav <> Wed, 20 May 2020 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3133A0923 for <>; Wed, 20 May 2020 05:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mB8tnqon2O7j for <>; Wed, 20 May 2020 05:23:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A047C3A0924 for <>; Wed, 20 May 2020 05:23:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=K4b3/uZ5tKVrqW9CYYpsO3M18eJHfzIs3idLZ88i9plmAbimr6/4dtcKKXifYpkl7mxThTBH97otDuSGqhrKDp3X3SS3Wpp0c/duNHcLu66MbjaG3PMEeMWV7xcn8MjTwSYCeQDFiGeCWkwjMW/ofiVMzxID0W9zdgTLkNi4xq0QO+vWxl3wt4XV5m6NJD5y0SJp3/C9OtZBf0wC3J5pZ2FF14GNj1gm8fYCrykMlXlGpifBSh3JRWcguV2uPQ1ABdqsDBqfO9qW1Z6WI0bwgTfSCvGyVHsfevXF5iPcsYGEqHb17yGCa/9USuFOyniCL/mvVRxi4/io2s4y1UNoZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AaHJbLoFctsclFB2b1zOrTpvHYoQPgHhx2E/lMu6CJI=; b=CsVnIWVfYVNEJiM/wA5Z0xGNfChJaP3ZBtWJkiA7WdAEeXVwfxtupLBaKZPVE2mi97YxyiddoUKLUpwyvO7kwFHRIz72K5THxUTA9GuriIPjv1UNp/8LKQ1IbgctY0aCg1imSS20NWnwvGq0oWRVsQmrMyg3GPPGhEzEf695yzPFny80FBFkKe8Lp46LKvfHO/2otJqm9QSdLeu5kiDutqAjbDg4EDSOr5xFWa/DzdQjRs4R6KBpWqaEMFa9in7I9sNil5Edzk9YQj9AuZyhAyeA30leHvghNrszX8tc+UOw2nUu04VZGSQYjq6Juv+ZKpRhjd53bwUf5Yt1g3xVYQ==
ARC-Authentication-Results: i=1; 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AaHJbLoFctsclFB2b1zOrTpvHYoQPgHhx2E/lMu6CJI=; b=O6xsF1ZGZIbTjnoeRH7DIFRJO1JJ6ucZ7FjqNnPk30XFpShzeOXw13kytS4FqXatZ4pKR3ev6xH6VN+W/PovSXI8wrkhGeLuw1hMN5w8vnkQqdrNEUqX64Rw4pcRFCc8gNvr1IfToDimOhvLNjI9c2siMyT+TKImuhyoho4iXN6rnkVapkEDtHCxQhytfxaT8yguV0Zq46qx0FaSQ3rLpU4DVK0/sVyDhQ0tf+diELRy0T46Caguh0yU/4IJHhOpxB922uZeTR6cUqRUBKDxc7R8tViXoXE47hwTDXvfjr4VQXA9Arv6scuhWOl9CVz6IoG9KA2H6059pSxF7n/Uwg==
Received: from (2a01:111:e400:7ebd::46) by (2a01:111:e400:7ebd::483) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Wed, 20 May 2020 12:23:20 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (2a01:111:e400:7ebd::51) by (2a01:111:e400:7ebd::239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Wed, 20 May 2020 12:23:19 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.3000.034; Wed, 20 May 2020 12:23:19 +0000
From: Rahul Jadhav <>
To: "Georgios Z. Papadopoulos" <>, Rahul Jadhav <>
CC: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt
Thread-Index: AQHWLpw9diGZYLfMm0qdFPHkjICT4aiw36iy
Date: Wed, 20 May 2020 12:23:19 +0000
Message-ID: <BM1PR01MB402038551375947D3DD87872A9B60@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <> <BM1PR01MB4020422CFBBF9205B39DF0E8A9BA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <>
In-Reply-To: <>
Accept-Language: en-IN, en-US
Content-Language: en-IN
x-incomingtopheadermarker: OriginalChecksum:73FBAAD6962E718155BA540BFD0A70B4B31D57B9718E10636F4946F58A3C97FB; UpperCasedChecksum:EF0DBBFF1E308A2FE4423B3BF03BA6D1FC19771EFBC32DF13121601713C58456; SizeAsReceived:7115; Count:45
x-tmn: [TdDYXhcAdxl15FBhPQn+AXFPxB6cK6VC]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 99043e83-f2de-4bb0-4e48-08d7fcb894ef
x-ms-traffictypediagnostic: SG2APC01HT155:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G4aRN30NlI20qjh/vhTjWKFqljOW0wKhakIV/yLnm5ZNpAqAU+TgkffKKjd/ZS1EGTgsTlbUUmg4BosLrRUpPyo8UHKpkplAphECsMaOROSoGYC2XaCnpaPgBPcKkG3wlRQWG58QlHEqEBcTB8WW+bUhquMALeHGK+TwsmbEecbIfANqvjunR029cWqa2+DcC+kMBrUJ0c4nOD/Ft2SU+9aTOEltdNKfYLtmcowrQ0zLWg8Otm6U51p1Y441hdSL
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: ZVd/fK15YFuV5Q/c7MYQIeLL42dhmtB4S5TeYV4kbyzhiRi/3Mi3UxwNAqoL77U4cYYsEg/B3SmiCuhoa6aKhzEqDs9dS21YOZ3nWYGE03QeTkZ+E285N5F7dfyfCuDycf8uhyNy0rJtWxJYP5/4Hw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402038551375947D3DD87872A9B60BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 99043e83-f2de-4bb0-4e48-08d7fcb894ef
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 12:23:19.7828 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT155
Archived-At: <>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 May 2020 12:23:27 -0000

Thank you very much Georgios for the review. Greatly helps.

Please find my responses inline.


From: Georgios Z. Papadopoulos <>
Sent: 20 May 2020 07:45 PM
To: <>; Rahul Jadhav <>
Cc: Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

Hello Rahul,

Many thanks for the updated version.
I went through it today, and yes, it is in much more better shape now.

Below you will find my comments on this version :

High level comments :
- Section 2.1, second paragraph : “A router may use capabilities carried in DIO message as additional metrics/constraints.”.
[GP]: One may ask : what prevents to have multiple metrics in DIO messages, without using the capabilities?

[RJ] Metrics/Constraints particularly aid the nodes to make a decision on the preferred parent selection. While capabilities are (possibly optional) features supported by the nodes. A 6LN/6LR may decide to use the parent node supporting a specific capability as compared to other upstream 6LRs. But the ultimate aim of capabilities may not necessarily be to make routing decisions. Take the case of 6LoRH. This cannot be signaled as a metric/constraint.
Another important difference is that routing metrics/constraints only flow downstream in DIO messages. Capabilities may go in either direction and can be queried.

- Section 4.1, first sentence : “A node MUST drop or discard the message silently having an unknown capability with ’D’ (discard) flag set.”
[GP]: This sentence is not clear to me. Why a node would send an unknown to itself D flag to its neighbors. Could you please rephrase it?
[RJ] The case is that a node receives a capability from other node  for e.g., in a DIO message with D flag set. If the node does not understand this cap then it should discard the DIO. As an example, a node may decide to send a cap with D flag set because it wants only the nodes who understand this cap to be in its sub-dodag.

- Section 4.1.1, second paragraph : “If the node is operating as 6LR and subsequently it receives a capability which it doesn’t understand with ’J’ flag set, then the node has to switch itself to 6LN mode.”
[GP]: This part is not clear to me. Why a 6LR should switch? I mean, simply because a neighbor node sends a DIO control packet with J that it does not understand? What is the ultimate objective by doing so?
[RJ] If a node receives a DIO with cap which it does not understand and has J flag set then it can join only as 6LN to this parent. As an example, consider 6LORH again. It may be possible to support 6LoRH in a network in which only the leaves don't understand 6LoRH. In this case, a root may send a cap with 6LoRH enabled with J flag set such that any node which doesn't understand this cap joins only as a leaf.

- Setion 5.2 : I liked very much your description and justifications here.
[GP]: Do you think would be possible to add here an example/figure with a simple topology to visualise the procedure.
[RJ]: I think It is possible to explain this in detail, especially considering PDAO as an example. Btw, most of this description comes from Rabi (thanks to him).

Minor comments/typos/rephrasing :
- [GP]: 1. Introduction, page 2, second paragraph, first sentence : “This document adds a notion of capabilities using which the nodes in the network” —> "This document adds a notion of capabilities using which nodes in the network”? (without THE nodes?)

- [GP]: 1. Introduction, page 2, second paragraph : “Mode of operation”, you already defined it earlier in the previous paragraph, you may write directly MOP, or keep o from operation in capital.

- [GP]: Section 2.1, 1st paragraph : Mode of Operation (MOP), you define it for the second time in the document.

- Section 4.1.1, 1st sentence : “On receiving a capability it does not support”
[GP]: You mean the following : A non-RPL node on receiving a capability that it does not support

- [GP]: Next paragraph : doesn’t understand with ‘J’ —> does not

- In the same Section, last paragraph : “Capabilities are used to indicate a feature that is supported by the node.  Capabilities are not meant for configuration management for”
[GP]: Maybe these sentences you should put move on section what is capabilities?

- [GP]: At the end of this paragraph : ./>, you might need to recompile it :-)

[RJ] Many thanks for the detailed read/review. Will incorporate all these fixes in next rev.

— —
Best, and stay safe,

On May 16, 2020, at 10:51, Rahul Jadhav <<>> wrote:

Dear all,

The update fixes all the points discussed during interim and subsequent ML discussions, namely:

  1.  Flag for ignoring (silently discarding) the message if cap not understood.
  2.  removal of global flag
  3.  removal of info present flag. Earlier we had optional length for capabilities who do not have any information. Such capabilities are now aggregated as part of 'Capability Indicators'.. Thus this bit is no longer required.
  4.  The indicator bits are ordered from left to right.

Feedback/reviews are appreciated. Thanks.


From: Roll <<>> on behalf of<> <<>>
Sent: 16 May 2020 04:41 PM
Subject: [Roll] I-D Action: draft-ietf-roll-capabilities-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : RPL Capabilities
        Authors         : Rahul Arvind Jadhav
                          Pascal Thubert
                          Michael Richardson
                          Rabi Narayan Sahoo
        Filename        : draft-ietf-roll-capabilities-04.txt
        Pages           : 12
        Date            : 2020-05-16

   This draft enables the discovery, advertisement and query of
   capabilities for RPL nodes.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

Internet-Drafts are also available by anonymous FTP at:

Roll mailing list<>
Roll mailing list<>