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

From: Rahul Jadhav <[email-masked]>
Date: Tue, 10 Dec 2019 09:13:02 +0800

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.

The RPL Status carrying ND Status seems not adequate,
1) RPL Status can carry only lower 6bits of the 8bits of ND Status
2) RPL Status and ND Status may not always be correlated.

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.

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.

Regards,
Rahul

[1] https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-07

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Dec 2019 10:01:27 +0000

Hello Rahul

Fair point. Please see below

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
> Sent: mardi 10 décembre 2019 02:13
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
> 
> 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].
> 
> 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.

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

> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Dec 2019 11:36:13 -0500

> Use of RPL status to carry ND status. ND Status (RFC 8505) is 8bits,

Forgive my slowness, new documents don't always seep into my brain quickly.
Is this RFC8505 section 9.4, ARO Status Values?
I can't find ND status in 8505 :-)
I re-read section 7 of unaware leaves, but I'm afraid I'm having difficulties
knitting all the pieces together.
(I suppose it is time to write code, it's the only way stuff sinks in for me)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 11 Dec 2019 09:01:27 +0800

> I can't find ND status in 8505 :-)

[RJ] I was referring to Table 1 in Section 4.1 but I guess the table
in Section 9.4 is the same. But yes, these are indeed ND (E)ARO status
codes. Sorry for the confusion.

> knitting all the pieces together.

[RJ] I think the 'A' bit in section 7 which says that the RPL status
is originated from ND EARO is the central point here. ND is using
RPL's base object Status field to propagate its status.
RPL Status field is getting used as of now in, DAO-ACK [RFC6550] and
DCO [efficient-route-invalidation draft].
My reason to start this discussion was to clarify the intersection
between ND/RPL to WG and the conclusion of this discussion will lead
to another mail wherein I would like to propose final changes to DCO's
Moved status value (which is currently 130).

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Dec 2019 09:29:08 +0000

Yes, and we need to fix the bug (130) one way or another : )

This is not an easy problem but I guess one "Ockham razor" is to consider the 

> Sent: mercredi 11 décembre 2019 02:01
> Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
> 
> [RJ] I was referring to Table 1 in Section 4.1 but I guess the table in Section 9.4 is
> the same. But yes, these are indeed ND (E)ARO status codes. Sorry for the
> confusion.
> 
> > I re-read section 7 of unaware leaves, but I'm afraid I'm having
> > difficulties knitting all the pieces together.
> 
> [RJ] I think the 'A' bit in section 7 which says that the RPL status is originated
> from ND EARO is the central point here. ND is using RPL's base object Status field
> to propagate its status.
> RPL Status field is getting used as of now in, DAO-ACK [RFC6550] and DCO
> [efficient-route-invalidation draft].
> My reason to start this discussion was to clarify the intersection between
> ND/RPL to WG and the conclusion of this discussion will lead to another mail
> wherein I would like to propose final changes to DCO's Moved status value
> (which is currently 130).
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Dec 2019 09:36:13 +0000

Sorry my mail went out unfinished

We must fix the 130 bug and Rahul's checking with the ML makes great sense.

The Ockham's razor of the day is probably energy conservation. We have a RPL status that uses 8 bits and has no value defined. We need to transport the EARO status to map between RPL and ND (for RUL and BBR). Should we insert a new field or merge the RPL and ND status. So far we went from the merge. Initially it was a mapping but Alvaro's review made us change that. Now it is an implicit transport of ND status inside RPL status, with the caveats that Rahul points out, mostly that the RPL status only has 6 bits to transport the EARO status that is 8 bits at this moment.

My suggestion to solve this is to reduce the size of the EARO status on the next occasion, which will free 2 bits for ND use in the EARO, and in the meantime ensure that values > 63 are not assigned at IANA review. We can write a quick fix at 6lo if that helps feel better.

Al the best,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2019 12:48:08 -0500

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

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)

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

If we can map or redefine (to have a single IANA registry) things, then i
prefer that over a new option.

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

It seems that we need to decide this as part of architecting the RUL, right?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Dec 2019 17:59:52 +0000

Hello Michael:

> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: mardi 17 décembre 2019 18:48
 
Yes, or mandate that the 64 first Status values are reserved for stuff that could be carried in RPL

> carried
> If we can map or redefine (to have a single IANA registry) things, then i prefer
> that over a new option.

We had a mapping in a earlier version and Alvaro actually pushed back. I see his point, the way it is now done allows an implementation of RPL to carry transparently a ND Status, so if ND defines new values they can be transported as well.

> we may

Well that's an open discussion of positioning RPL and ND. 

For the case of adding ND options in DIOs, e.g.,  SLLAO, this does not help a RUL since the RUL does not parse the DIO messages.

Not sure what your point is though?

Pascal

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 18 Dec 2019 08:21:10 +0800

> 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,
future extensions to ND ARO status need to consider whether they are
applicable to RPL and define accordingly. This implies familiarity in
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!

---

From: Michael Richardson <[email-masked]>
Date: Fri, 27 Dec 2019 01:28:17 -0500

Rahul Jadhav <[email-masked]> 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)
    >> 

    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.

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

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Rahul Jadhav <[email-masked]>
Date: Sat, 28 Dec 2019 12:36:29 +0530

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