Subject: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option

From: Rahul Jadhav <[email-masked]>
Date: Thu, 4 Jun 2020 07:44:18 +0000

Hello All, Pascal,

Based on my understanding currently, the draft serves three purposes:
1. Helps elide common DIO options which rarely change
2. Helps elide common DAO options during route refresh cycles
3. Allow sync for individual protected options by assigning RCSS to an option (this implies the use of new AOO)

Points 1 and 2 are quite clear and easy to follow.

The whole complexity of the proposal lies in point 3 and from what I understand I believe the utility is not convincing enough for the amount of complexity it introduces.

My understanding is that with AOO, it is possible that a Root assigns a different RCSS to individual protected options such that the downstream nodes can individually query and synchronize with any of that option on change.

My rationale is that PIO/RIO/DODAG Configuration/MOPex/GCO options rarely change. IMO, if either of it changes then it is no big deal to advertise all the options. Rather than managing versions for each of these options, the RCSS can only be a common counter for all the options.

I understand that RCSS of an option is "an extension" and it is possible to only use common RCSS. But I believe the whole RCSS of an option as an extension is adding to the complexity of the draft (introducing more scenarios to handle), and also making it difficult for the reader.

Best,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jun 2020 09:12:59 +0000

Helo Rahul

Many thanks for this. For RPLv2 we said at the interim that triggered this draft that we want to unsure that:
- a configuration may change in run time to enable new services / brown field (not just the config option, that can be , say, the PIO)
- messages can be lost in transmission, nodes sleep, there are tons of reason why a node may miss a change
- we cannot place all options in all DIOs all the time
- even if we did, if one parent has an old version and another parent has the new, how does the child know which is good?

Bottom line is that we cannot compress an option that may change over time if there is no way for a node to know that it has the latest or not, and  obtain the latest immediately if not.

> My understanding is that with AOO, it is possible that a Root assigns a different RCSS to individual protected options such that the downstream nodes can individually query and synchronize with any…

Well there is only one RCSS value that is monotonically incremented and covers the whole DIO, with virtually all the options in it. The RCSS is incremented each time one of the options changes.

The RCSS associated to the last change of a given option sticks to that option. So when a node needs to know whether an option changed, it looks for the RCSS of the last change for that option and compares with the RCSS of the last change it is aware of. This is very similar to using sequence counters is classical in db sync, e.g., in link state protocols.
- the difference is that we use a same counter for all options, as a small economy. Is that where you find extra complexity ?
- you can use hashes too, hash each option and place the hash in the AOO, but there's a chance of false negative. Would you rather do that?

> My rationale is that PIO/RIO/DODAG Configuration/MOPex/GCO options rarely change. IMO, if either of it changes then it is no big deal to advertise all the options. Rather than managing versions for…

I understand that you propose to send all the options when a single one changes. This alleviates the need to remember the RCSS associated to each individual option and removes the need for the AOO. So it's a trade of between the size of the DIOs and the complexity of advertising and maintaining them separately.

We are building and infrastructure that will have certain properties; if all options must be there when one option changes, we'll be more constrained in how many options we can create and how often they change. The proposed dichotomy pays additional complexity now for extra freedom in the future.

I'd like to see other chime in on this.

Take care,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: jeudi 4 juin 2020 09:44
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option

Hello All, Pascal,

Best,
Rahul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2020 19:57:35 -0400

{I feel I am increasingly distant from these things.  Too long since I wrote
code, I think}

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > Well there is only one RCSS value that is monotonically incremented and
    > covers the whole DIO, with virtually all the options in it. The RCSS is
    > incremented each time one of the options changes.

    > The RCSS associated to the last change of a given option sticks to that
    > option. So when a node needs to know whether an option changed, it
    > looks for the RCSS of the last change for that option and compares with
    > the RCSS of the last change it is aware of. This is very similar to
    > using sequence counters is classical in db sync, e.g., in link state
    > protocols.

I feel a bit that maybe we are re-inventing a wheel here.
Maybe we should be doing more with DHCPv6?

Without really changing anything, I wonder if we should think of the AOO are
really just moving configuration out of the DIO into another place, and
rather than trickle flooding the configuration, we trick flood the
configuration reference.

Nodes without the new data need to fetch it.
Sometimes a 6LR will need to fetch that before a 6LR can move from leaf to router.
Maybe always.  Maybe if a flag is set.

What I'm trying to say here is that maybe we should thinking of the
configuration update process as a network service, which we happen to
leverage for network configuration, but also can be leveraged for application
configuration.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jun 2020 10:15:38 +0800

> leverage for network configuration, but also can be leveraged for

[RJ] True, This is something we should keep in mind even for capability
options. Generic capabilities that are not related to the routing process
are best kept out of the scope of RPL/ROLL and have something generic such
as 6lo-MLE(now expired) or CORECONF to handle such configuration
query/management.
However, for RCSS as an option, I am not sure if this applies. RCSS is very
RPL-specific.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>