Re: [Roll] capability vs. configuration

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

Hello Li:

The draft is written so that we can live with node that have seen the flags and nodes that have not seen it, as long as all nodes support RFC 8138.
The point is that a node must keep the packet in its form, compressed or not, so the format of the packet will only depend on whether the source saw the flag or not.
IOW nodes always accept to process a packet that is encoded with RFC 8138, but they can only source such a packet if they saw the flag.

We could have text to clarify that as well in the applicability.

Does that work for you?

Pascal

From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
Sent: lundi 27 mai 2019 09:45
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] capability vs. configuration

Hello Pascal,

Flag day idea looks good for me. And we should note two points:

  1.  Some battery node need long time to sync flag day from DIO
  2.  Some node doesn’t have UTC time. Maybe we should use time drift to identify flag day?

Best regards,
Li

From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>>
Reply-To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 27, 2019 at 2:37 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] capability vs. configuration

Hello Li

I think we agree and I think you still support the turnon_8138 draft. In more details: the flag is useful in a transition till all nodes are converted to ensure a continuity of operation during a transition.

A network with the flag off and hybrid support works. When all nodes support RFC 8138 and as the new config spreads only a few saw the flag things still work, you’ll see packets of both types but all will be forwarded.
But rolling back the flag is not guaranteed to work fully before a long time since a node here and there may still be missing the update of the DIO and keep on using RFC 8138.

I think that what is true there is true also for useofrplinfo. The flag is used to delay the use of the new feature till the flag day. Once the flag day is passed, that’s it for all.

The capability is good to reassure the admin that all nodes are upgraded and ready. If after that the admin deploys  a back level node, his mistake.

Now we can work on minimizing the damage. E.g. we can add text to say that a child cannot forward an RFC 8138 via a parent that does not set the flag. But then, we’d need the parent to express his capability and that’s again an interaction with the capability draft. Note that the parent cannot change the config option and must forward it as is, whether it understands it or not.

Also, the root must encaps with RFC 8138 only along a path that is known to support it. E.g., if the child does not then the root can encapsulate to the parent ip in ip, and leave native RFC 6775 in the inner packet.

Doe sthat look good ?

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Li Zhao (liz3)
Sent: lundi 27 mai 2019 07:19
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] capability vs. configuration

Hello Pascal,

My point is that dynamic switch the capability too frequently or too easily is not good. At least we need some rule to limit the switch capability.

For example, if a root forms a network with 1000 nodes which supports 8183. What should root do when it receives a non-8138 compatible DAO? Reject this node or switch the whole network to non-8138. It’s hard to decide by root itself.


Best regards,
Li

From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>>
Reply-To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 27, 2019 at 1:08 PM
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] capability vs. configuration

Hello Li

I do not understand your point that the capability to switch to 8138 is not a good idea.
I understand it is better to avoid the situation but sometimes you have no choice. And if you upgrade a first node in the middle of the network then there are no parent to form a dodag.

Bottom line is you upgrade all your nodes and then you set the flag in the capability.

What do I miss?


Regards,

Pascal

Le 27 mai 2019 à 05:24, Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>> a écrit :
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.

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