Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage

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

Hello Rahul

Fair point. Please see below







> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Rahul Jadhav
> Sent: mardi 10 décembre 2019 02:13
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
> 
> Hello Pascal, Michael, All,
> 
> I would like to open the discussion about carrying the ND Status as part of the
> RPL Status as mentioned in the Unaware-leaves draft [1].
> 
> The proposition by Unaware-leaves draft wrt RPL status is:
> Use of RPL status to carry ND status. ND Status (RFC 8505) is 8bits, and RPL
> status is 8bits. RPL status MSB is already used to indicate outright rejection.
> Unaware-leaves draft dedicates 2nd MSB in RPL status to indicate ND status.
> This means only lower 6-bits of ND Status can be at most carried in RPL status.

It would have been immensely nicer to use the leftmost bit in ND's RC to indicate error as we do in RPL but the art was not like that. So we cannot converge on that bit with backward compatibility, sad thing.

> 
> The RPL Status carrying ND Status seems not adequate,
> 1) RPL Status can carry only lower 6bits of the 8bits of ND Status

As you point out, it will be trouble if the ND status exceeds 64 values. Do you know any status in any RFC that does that? Can you figure the case switch that tests them all with a different behavior each?
Seems more sensible to downgrade the 6lo RC to 6 bits on the next occasion.

> 2) RPL Status and ND Status may not always be correlated.

RPL must carry the ND status back whatever the status is. It's not just for RUL, it's for backbone router as well. It's actually cool that the way we defined now does not need to be aware of each value to do a mapping so the status can be transported transparently without changing a RPL spec each time ND changes (thanks to Alvaro).

The other way around, RPL only statuses can be transported with the second bit indicating so. So I do not see an issue there.


> 
> How about using a different ND Option in RPL messaging to keep the ND
> handling segregated? The unaware draft can say that this option can be carried
> in DCO or any other RPL message it requires. ND status/option may have to be
> carried only in specific cases which involves unaware leaves and as such the
> control overhead due to option header may not be much.
> 

Now, you as much as anyone have in mind that we design for a constrained space. We started with a mapping and Alvaro reacted to that. So we proposed the encapsulation that you describe. And now we'd have an new option? This seems really excessive when each bit counts. Note that so far there is not a single RPL status defined outside of those imported from ND, and each DAO-ACK is carrying 8 bits of zeroes all around the world in millions of devices. We better not increase the waste don't you think?

> This ND option could also be easily extended for future purposes since we may
> have additional fields in the future from ND to be carried with RPL.
 
RPL and ND are close family, RPL is effectively the way to support non-transit links (NBMA) that the original ND did not have. RPL carries ND options natively, consider PIO. I'm all for adding more options like SLLAOs in DIO, as we discussed at the meeting. So I fully agree with the desire/intuition. But we do not need an ND option for that, it's already meant to be this way.

What do others think?

Pascal