Re: [Roll] capability vs. configuration

["Li Zhao (liz3)" <[e-mail]>]

Hello Pascal,

My comments inline…

In order to decide whether  it can safely set the config flags, it would be good that the root knows about the node capabilities such as route projection, RFC 8138 compression and option x23 for RPI. So I thought that the node could expose that capability using mop-ext and we add the bits in the draft already.

[RJ] So the root is expected to set the T-flag after learning the nodes capabilities after the initial DIO-DAO round .. is this right? i.e. once the root learns that all nodes are 8138 capable then it sets the T-flag in the subsequent DIO (possibly after DTSN increment)? What happens if a node springs up later and announces that it does not support 8138 after the T-flag was turned on by the root ?

[Li] How to identify the initial DIO-DAO round is also a problem to deal with. Because the root doesn’t know the scalability/max hop/form time of each PAN.
One propose is adding scalability/form time as capability of root, root can detect initial DIO-DAO and then announces 8138 or option x23 to nodes.

For route projection, we could include a number of routes that the node can store, using a number like 10 hops max for non-storing PDAOs.

[RJ] Yes this could be done and will help route projection.

[Li] In non-storing PDAO, the route entries number and max hops are both needed as capabilities.

Best regards,
Li


From: Rahul Arvind Jadhav <[e-mail]>
Date: Saturday, May 25, 2019 at 9:18 AM
To: Routing Over Low power and Lossy networks <[e-mail]>, Li Zhao <[e-mail]>
Subject: RE: capability vs. configuration

As you know, we have a configuration option in standard RPL. It is used by useofrplinfo to trigger the use of option x23 and by https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00 to trigger the use of RFC 8138 compression.

This must not be confused with the capability draft in draft-rahul-roll-mop-ext which is how the nodes and the root share on what capabilities they have. A configuration is a flat order from the root, the capability is an exchange of information.

[RJ] By flat order, I assume you mean that all the nodes either support it or they don’t. There are no mixed nodes. In this case, yes, this is a candidate for existing configuration option rather than capabilities. I read the draft and I believe this to be true.

In order to decide whether  it can safely set the config flags, it would be good that the root knows about the node capabilities such as route projection, RFC 8138 compression and option x23 for RPI. So I thought that the node could expose that capability using mop-ext and we add the bits in the draft already.

[RJ] So the root is expected to set the T-flag after learning the nodes capabilities after the initial DIO-DAO round .. is this right? i.e. once the root learns that all nodes are 8138 capable then it sets the T-flag in the subsequent DIO (possibly after DTSN increment)? What happens if a node springs up later and announces that it does not support 8138 after the T-flag was turned on by the root ?

For route projection, we could include a number of routes that the node can store, using a number like 10 hops max for non-storing PDAOs.

[RJ] Yes this could be done and will help route projection.