Thanks Pascal, Looks like we are in sync in terms of what needs to be done in 6lo.
However for the DCO RPL Status code 130, please find my response [RJ] inline. ________________________________ From: Roll <[email protected]> on behalf of Pascal Thubert (pthubert) <[email protected]> Sent: 10 March 2020 07:44 PM To: Routing Over Low power and Lossy networks <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage Hello Rahul Sorry I was deep into the IESG review of other draft in C310. Let’s see below From: Roll <[email protected]> On Behalf Of Rahul Jadhav Sent: mardi 25 février 2020 06:03 To: Routing Over Low power and Lossy networks <[email protected]> Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage 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. Pascal > Correct 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. Pascal > Suggestion is to have a IANA action in this draft that limits the 6lo status registry to 64 values without changing any RFC, cc’ing 6lo see if we agree on this. Pascal > This change would be backward compatible with the current ND drafts. > c) Action Point? > Ans: Limiting ND status code to 64 values needs to be informed to 6man/6lo > through an update. Pascal > Agreed, cc’ing 6lo. 6MAN did not contributed to the 6LoWPAN ND status so far. [RJ] Looks like we are in sync for all the above points. 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. Pascal > Moved is 3 in 6lo (https://tools.ietf.org/html/rfc8505) 3 | Moved: The registration failed because it is not the most | | | recent. This Status indicates that the registration is | | | rejected because another more recent registration was | | | done, as indicated by the same ROVR and a more recent | | | TID. One possible cause is a stale registration that has | | | progressed slowly in the network and was passed by a more | | | recent one. It could also indicate a ROVR collision. Pascal > If we say that Value is the 6Lo status we want 128 + 3, and get 131. I think that’s the point we wanted to make. Dec Hex Oct Bin 131 83 203 10000011 Pascal > Same here, am I missing something here? Any comments? [RJ] But the 6lo value is applicable only when 'A' bit is set. With 'A' bit unset, as is the case above, RPL is free to choose its own values for the remaining 6bits. Isn't it? I was assuming that the 6-bit registry will not be common between 6lo Status Code and RPL Status Code. Take care, Pascal On Sat, 28 Dec 2019 at 12:36, Rahul Jadhav <[email protected]<mailto:[email protected]>> wrote: On Fri, 27 Dec 2019 at 11:58, Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: > > > Rahul Jadhav <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
