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

[Rahul Jadhav <[e-mail]>]

I would like to summarize this discussion and mention the action points.

1. ND status as part of RPL status:
a) What we have right now?
Ans: 8-bit ND status to be carried in LSB 6-bit RPL status. Though RPL
status is 8-bit as per 6550, the unaware-leaves draft updates this field's
two MSBs to carry flags, thus leaving 6-bits for carrying ND status.
b) What could be the problem with this?
Ans:  Stuffing 8-bit status to 6-bit is possible today because the ND
status allocations are very few and as of now it looks as if reaching
values >=64 might not happen anytime soon. Anyways the problem is how would
6man/6lo know that RPL limits the range of the ND Status. Thus we need
6man/6lo to be informed.
c) Action Point?
Ans: Limiting ND status code to 64 values needs to be informed to 6man/6lo
through an update.

2. RPL status code for DCO (currently 130)
RPL Status code of 130 in DCO indicates that the address has moved i.e.,
somewhere below/downstream in the sub-dodag the target has changed parents.
It was discussed that 130 may not be an appropriate value but when I
checked again it seems all right.

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E|A|  Value    |
+-+-+-+-+-+-+-+-+
130 == 1000 0010
The E bit is set indicate rejection and A bit is unset to indicate non-ND
value.
Thus 130 seems to be the right value.
Action Point? No change if this rationale is correct.

Am I missing something here? Any comments?

Regards,
Rahul


On Sat, 28 Dec 2019 at 12:36, Rahul Jadhav <[e-mail]> wrote:

> On Fri, 27 Dec 2019 at 11:58, Michael Richardson <[e-mail]>
> wrote:
> >
> >
> > Rahul Jadhav <[e-mail]> wrote:
> >     >> > > You mean that we could change the ND status to 6-bits in the
> 6lo
> >     >> WG?  > (I would have parsed ND status as being someing 6man takes
> care
> >     >> of)
> >     >>
> >     >> Yes, or mandate that the 64 first Status values are reserved for
> stuff
> >     >> that could be carried in RPL
> >     >>
> >
> >     RJ> Wondering how such a mandate would work. IF we do it this way,
> >     RJ> future extensions to ND ARO status need to consider whether they
> are
> >     RJ> applicable to RPL and define accordingly. This implies
> familiarity in
> >     RJ> 6lo/6MAN with RPL.
> >
> >     > I prefer the other approach where we restrict the ND ARO status to
> >     > 64bits itself. Anyways using 128 bits in the future seems
> far-fetched
> >     > (as indicated by Pascal before). But to limit ND ARO status to
> 64bits
> >     > we need to convince the 6lo/6MAN group that "because of RPL" we
> need to
> >     > reduce the size. I am not sure if this is easy to digest!
> >
> > I thought that we had 6-bits to store 64-values, while ND has 8-bits to
> store
> > 256 values.  Please correct me if I mis-understood.
> >
>
> [RJ] Currently ND has 8bits to store 256 values ... RPL needs to carry
> the same 8-bits but currently it has space only for 6-bits in RPL
> Status field. But as of now only few values of ND status has been used
> and using up 256 values (or for that matter 64 values) seem
> far-stretched.
> Thus one of the opinions is to limit the ND status to 64-bits and
> carry as-is in the RPL status.
>