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

[Rahul Jadhav <[e-mail]>]

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

Please find my responses inline.

Best,
Rahul


________________________________
From: Georgios Z. Papadopoulos <[e-mail]>
Sent: 20 May 2020 07:45 PM
To: [e-mail] <[e-mail]>; Rahul Jadhav <[e-mail]>
Cc: Routing Over Low power and Lossy networks <[e-mail]>
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,
Georgios


On May 16, 2020, at 10:51, Rahul Jadhav <[e-mail]<mailto:[e-mail]>> 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.

Best,
Rahul


________________________________________
From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: 16 May 2020 04:41 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-capabilities/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-capabilities-04
https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-capabilities-04


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll