Subject: [Roll] capability vs. configuration

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 May 2019 13:00:20 +0000

Dear all

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.

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.

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.

Wat do you think?

Pascal

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sat, 25 May 2019 01:17:37 +0000

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

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

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

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 27 May 2019 02:57:44 +0000

Hello Pascal,

My comments inline…

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

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

Best regards,
Li

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

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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Mon, 27 May 2019 03:12:19 +0000

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

Best regards,
Li

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 27 May 2019 10:02:55 +0200

On Fri, May 24, 2019 at 3:01 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all
>
> *   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
> <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.*
>

they need to be dealt/considered in different ways.

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

route projection is not a capability and must not be one.

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

don't agree because we need to separate projection from storage.

> *   Wat do you think?*

I don't think this route projection is important for RPL, however it can be
an option to be used for configurations.

AB