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

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

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