Re: [Roll] capability vs. configuration

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

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.

[RJ]  What happens if a non-8138 compatible node springs up later (i.e., after root has announced T-flag set in DIO) and advertises that it is not 8138 capable ? Would root in turn start updating the network to reset T-flag in DIO? In this case there could be 8138 compressed traffic in-transit while the unsetting of T-flag is in progress.

[Li] The mixed 8138 and non-8138 network should not be common case when deployment. It’s usually existing during upgrading firmware. Dynamic switch 8138/non-8138 by root is not a good idea.
If it’s indeed a mixed network, two instances(one for 8138 and another for non-8183) is a workaround.

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]<mailto:[e-mail]>>
Date: Saturday, May 25, 2019 at 9:18 AM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>, Li Zhao <[e-mail]<mailto:[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.