Subject: [Roll] signaling RPI option value and support of RFC 8138 in RPLv2

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Dec 2019 09:35:45 +0000

> [Rahul asked] I would like to confirm a point here... Reclaiming the turnon-8138 flag in MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above MOP>=7 such that they no more depend on this flag. This in itself is a bigger decision! Is my understanding correct? While the advantages of 8138 are obvious in non-storing MOP case, they are less impacting/obvious in storing MOP case. 

The configuration bits can be reclaimed if the value is always-on or always off for a new MOP. When defining a MOP, it is possible to indicate either way and then to reclaim the bits. I see that MOPext could say, individually for each bit:

a) For any MOP >= 7, the bit is implicitly always on (or off) unless the MOP specification says otherwise

b) For any MOP >= 7, the MOP specification MUST either indicate that the bit is used as for MOP<7 or provide an implicit setting

c) For any MOP >= 7, the bit is implicitly as for MOP<7 unless the MOP specification says otherwise

My preference goes to a), defaulting both settings to on. My rationale is this:

. A default value simplifies the writing of the MOP specs.

. For the RPI option type, we deprecated the value 0x63 and RPLv2 seems like a good flag day. I expect that no MOP > 7 will ever turn it back on. But if we were wrong doing this, then a MOPext bis can always reverse the default above another step of MOP.

. For the RFC 8138 turnon bit, even in storing mode, there's IP in IP for packets coming from the outside to insert a HbH header, and compressing those 2 is already a huge saving. I'd also argue that all known implementations for constrained environments support non-storing, so the code should be there. I'm not sure it's a huge footprint in the devices, considering the value in each packet, it's certainly worth it. Finally, the nex RPL signaling (P DAO and RUL) already uses RFC 8138 to compress the RPL control packets.

What do other think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2019 13:00:36 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    Rahul> I would like to confirm a point here... Reclaiming the turnon-8138
    Rahul> flag in MOP>=7 would mean that 8138 is _mandatorily_ supported in
    Rahul> the nodes above MOP>=7 such that they no more depend on this
    Rahul> flag. This in itself is a bigger decision! Is my understanding
    Rahul> correct? While the advantages of 8138 are obvious in non-storing
    Rahul> MOP case, they are less impacting/obvious in storing MOP case. 

    > The configuration bits can be reclaimed if the value is always-on or
    > always off for a new MOP. When defining a MOP, it is possible to
    > indicate either way and then to reclaim the bits. I see that MOPext
    > could say, individually for each bit:

    > the MOP specification says otherwise

...

    > My preference goes to a), defaulting both settings to on. My rationale is this:

I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 20 Dec 2019 22:57:33 +0200

On Thu, Dec 12, 2019 at 11:36 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> > [Rahul asked] I would like to confirm a point here... Reclaiming the
> turnon-8138 flag in MOP>=7 would mean that 8138 is _mandatorily_ supported
> in the nodes above MOP>=7 such that they no more depend on this flag. This
> in itself is a bigger decision! Is my understanding correct? While the
> advantages of 8138 are obvious in non-storing MOP case, they are less
> impacting/obvious in storing MOP case.
>
> always off for a new MOP. When defining a MOP, it is possible to indicate
> either way and then to reclaim the bits. I see that MOPext could say,
> individually for each bit:
>
> b) For any MOP >= 7, the MOP specification MUST either indicate that the
> bit is used as for MOP<7 or provide an implicit setting
>
> .. A default value simplifies the writing of the MOP specs.
>
> .. For the RPI option type, we deprecated the value 0x63 and RPLv2 seems
> like a good flag day. I expect that no MOP > 7 will ever turn it back on.
> But if we were wrong doing this, then a MOPext bis can always reverse the
> default above another step of MOP.
>
> .. For the RFC 8138 turnon bit, even in storing mode, there's IP in IP for
> packets coming from the outside to insert a HbH header, and compressing
> those 2 is already a huge saving. I'd also argue that all known
> implementations for constrained environments support non-storing, so the
> code should be there. I'm not sure it's a huge footprint in the devices,
> considering the value in each packet, it's certainly worth it. Finally, the
> nex RPL signaling (P DAO and RUL) already uses RFC 8138 to compress the RPL
> control packets.
>
> What do other think?
>

I did not agree with this use of config bit in the first place and said it
is complicated, as you can see authors are confused. However, I think it is
not useful to make that  configuration bit depending on MOP,, the best
practise is separate both as independent.

AB