Re: [Roll] capability vs. configuration

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Li:

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.

<PT>The idea is that the admin decides at some point to do the switch, after the network has been up and operational, nodes have ben upgraded if needed, etc. Eventually all nodes are ready, the flags confirm that, and the admin presses the button. Over the next minutes, hours or days, the network will convert while never stopping, at least that is the goal of the draft. We could have a section on applicability, if you are willing to write it, Li?



[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.

<PT> I agree that going back is a bad idea. This is supposed to be used for flag day.



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.

<PT> Works for me.



All the best,

Pascal