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

[Abdussalam Baryun <[e-mail]>]

On Thu, Dec 12, 2019 at 11:36 AM Pascal Thubert (pthubert) <
[e-mail]> 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.
>
> 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?
>

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