Subject: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Oct 2019 11:39:48 -0700

Dear authors:

I reviewed the changes (only) and have some comments/questions.
Please take a look below.

I would like for my concerns to be addressed before sending the
document back to the RFC Editor.

Thanks!

Alvaro.

[Line numbers from idnits.]

384	4.3.  Destination Cleanup Object (DCO)
...
393	     0                   1                   2                   3
394	     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
395	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
396	     | RPLInstanceID |K|D|   Flags   |  RPL  Status  | DCOSequence   |
397	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
398	     |                                                               |
399	     +                                                               +
400	     |                                                               |
401	     +                            DODAGID(optional)                  +
402	     |                                                               |
403	     +                                                               +
404	     |                                                               |
405	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406	     |   Option(s)...
407	     +-+-+-+-+-+-+-+-+

[nit] s/RPL  Status/RPL Status   To make it easier to search, please
eliminate the extra space.

...
434	   RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550].
435	   Indicative of the reason why the DCO happened, the RPL Status MUST
436	   NOT be changed as the DCO is propagated down the route being
437	   invalidated.  This value is informative and does not affect the
438	   behavior of the receiver.  In particular, unknown values are ignored
439	   by the receiver.  Only Rejection Codes (values of 128 and above) are
440	   expected in a DCO.

[major] rfc6550 defines a field called "Status" (not "RPL Status") for
the DAO-ACK, which "Indicates the completion", and not "the reason why
the DCO happened".  Also, the value of "130 indicating that the
address has moved" is not consistent with what seems to be intent in
the DAO-ACK: "Rejection; the node sending the DAO-ACK is unwilling to
act as a parent."   While the interpretation could be stretched, it
seems to me that it would be better to simply create a new "RPL
Status" field/registry that applies specifically to the DCO.

>From the discussion on the list, it was proposed that a common
registry can be defined in draft-ietf-roll-unaware-leaves.  Looking at
that draft, and the fact that it defines "RPL Status values for use in
DAO-ACK and DCO that map the 6LoWPAN ND values defined in Table 1 of
[RFC8505]", where 130 is called "Moved", but the definition in rfc8505
refers to a stale registration...  IOW, the use of 130 doesn't seem to
map well to the definitions in rfc8505.  This seems to be another
reason to create an independent field/registry.

Is there a strong reason for the reuse?

[major] "the RPL Status MUST NOT be changed...is informative and does
not affect the behavior of the receiver...unknown values are
ignored...Only Rejection Codes (values of 128 and above) are expected
in a DCO."

If the value doesn't matter (informative) and unknown ones are
ignored, why specify that it MUST NOT change?  What is the Normative
value of that?  Specifically, if the value was changed to something <
128, what should the receiver do?

...
574	4.5.  Unsolicited DCO

576	   A 6LR may generate an unsolicited DCO to unilaterally cleanup the
577	   path on behalf of the target entry.  The 6LR has all the state
578	   information, namely, the Target address and the Path Sequence,
579	   required for generating DCO in its routing table.  The conditions why
580	   6LR may generate an unsolicited DCO are beyond the scope of this
581	   document but some possible reasons could be:

583	   1.  On route expiry of an entry, a 6LR may decide to graciously
584	       cleanup the entry by initiating DCO.
585	   2.  6LR needs to entertain higher priority entries in case the
586	       routing table is full, thus resulting in eviction of an existing
587	       routing entry.  In this case the eviction can be handled
588	       graciously using DCO.

590	   Note that if the 6LR initiates a unilateral path cleanup using DCO
591	   and if it has the latest state for the target then the DCO would
592	   finally reach the target node.  Thus the target node would be
593	   informed of its invalidation.

[] This section wasn't changed, but it seems to me that there's an
opportunity to indicate these known reasons as Status in the DCO.
Among other things, the target node would be able to identify the
reason for the unsolicited DCO...

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 17:33:32 +0000

Hello Alvaro:

...

[major] rfc6550 defines a field called "Status" (not "RPL Status") for the DAO-ACK, which "Indicates the completion", and not "the reason why the DCO happened".  Also, the value of "130 indicating that the address has moved" is not consistent with what seems to be intent in the DAO-ACK: "Rejection; the node sending the DAO-ACK is unwilling to act as a parent."   While the interpretation could be stretched, it seems to me that it would be better to simply create a new "RPL Status" field/registry that applies specifically to the DCO.

<Pascal> I agree that we are making it a "reason". This is consistent with the evolution of the status and its use in RFC 8505, more below.

>From the discussion on the list, it was proposed that a common
registry can be defined in draft-ietf-roll-unaware-leaves.  Looking at that draft, and the fact that it defines "RPL Status values for use in DAO-ACK and DCO that map the 6LoWPAN ND values defined in Table 1 of [RFC8505]", where 130 is called "Moved", but the definition in rfc8505 refers to a stale registration...  IOW, the use of 130 doesn't seem to map well to the definitions in rfc8505.  This seems to be another reason to create an independent field/registry.

<Pascal> We have complex flows where the 6LBR proxies the 6LN's registration to the 6BBR (https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) so that in turn the 6BBR does ND proxy for the 6LN on the backbone. We use RFC 8505 between the 6LN and the 6LR, and between the 6LBR and the 6BBR. In case of a bad RC from the 6BBR to the 6LBR, the 6LBR needs to send the information back to the 6LR so the 6LR returns it to the 6LN using RFC 8505. We use NP DAO for that and for that reason, yes, we stretch the meaning. As you see the point is not to save a registry but to homogenize the RPL and the RFC 8505 status. 

See https://tools.ietf.org/html/rfc8505#section-9.4 and https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04#section-12.2 : )

When the address moves on the backbone, the RPL state in the old DODAG is Cleaned from the 6LBR down. And the status from 6BBR to 6LBR is moved so the expectation is that it percolates down. The rejection is mostly to cleanup RPL since the leaf is expected to be long gone and registered in a different DODAG across the backbone.

[major] "the RPL Status MUST NOT be changed...is informative and does not affect the behavior of the receiver...unknown values are ignored...Only Rejection Codes (values of 128 and above) are expected in a DCO."

If the value doesn't matter (informative) and unknown ones are ignored, why specify that it MUST NOT change?  What is the Normative value of that?  Specifically, if the value was changed to something < 128, what should the receiver do?

We wish the information to be known by all nodes, and this is a provision that we can reliably act differently per status value all the along the DODAG in the future. So we see this as protecting the future. Is that a problem?

...
574	4.5.  Unsolicited DCO

[] This section wasn't changed, but it seems to me that there's an opportunity to indicate these known reasons as Status in the DCO.
Among other things, the target node would be able to identify the reason for the unsolicited DCO...

Agreed, let's look at this.

Many thanks Alvaro, I'll look at this more tomorrow, based on how you react to the above.

Take care,

Pascal

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 24 Oct 2019 09:27:06 -0700

On October 21, 2019 at 1:34:54 PM, Pascal Thubert
(pthubert)([email-masked]) wrote:

Pascal:

Hi!

> > [major] rfc6550 defines a field called "Status" (not "RPL Status") for the
> > DAO-ACK, which "Indicates the completion", and not "the reason why the DCO
> > happened". Also, the value of "130 indicating that the address has moved"
> > is not consistent with what seems to be intent in the DAO-ACK: "Rejection;
> > the node sending the DAO-ACK is unwilling to act as a parent." While the
> > interpretation could be stretched, it seems to me that it would be better
> > to simply create a new "RPL Status" field/registry that applies
> > specifically to the DCO.
>
> I agree that we are making it a "reason". This is consistent with the
> evolution of the status and its use in RFC 8505, more below.
>
> > registry can be defined in draft-ietf-roll-unaware-leaves. Looking at that
> > draft, and the fact that it defines "RPL Status values for use in DAO-ACK
> > and DCO that map the 6LoWPAN ND values defined in Table 1 of [RFC8505]",
> > where 130 is called "Moved", but the definition in rfc8505 refers to a
> > stale registration... IOW, the use of 130 doesn't seem to map well to the
> > definitions in rfc8505. This seems to be another reason to create an
> > independent field/registry.
>
> We have complex flows where the 6LBR proxies the 6LN's registration to the
> 6BBR (https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/) so
> that in turn the 6BBR does ND proxy for the 6LN on the backbone. We use RFC
> 8505 between the 6LN and the 6LR, and between the 6LBR and the 6BBR. In case
> of a bad RC from the 6BBR to the 6LBR, the 6LBR needs to send the information
> back to the 6LR so the 6LR returns it to the 6LN using RFC 8505. We use NP
> DAO for that and for that reason, yes, we stretch the meaning. As you see the
> point is not to save a registry but to homogenize the RPL and the RFC 8505
> status.
>
> See https://tools.ietf.org/html/rfc8505#section-9.4 and
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04#section-12.2 : )
>
> When the address moves on the backbone, the RPL state in the old DODAG is
> Cleaned from the 6LBR down. And the status from 6BBR to 6LBR is moved so the
> expectation is that it percolates down. The rejection is mostly to cleanup
> RPL since the leaf is expected to be long gone and registered in a different
> DODAG across the backbone.

I think I understand -- homogenizing is not a bad thing. :-)

However, I am still concerned about a couple of things:

(1) the values are not the same...for example, "moved" in rfc8505 has
a value of 3, not 130.  Why not use the same value?  The answer to
this question overflows into my second concern...

(2) draft-ietf-roll-unaware-leaves doesn't update the allocation
guidelines from rfc6550 (§6.5.1) for the Status, which then lands
"moved" in the "Rejection" range.  IOW, the meaning is changed, but
the original meaning of the DAO-ACK Status is not updated...

[We are not reviewing draft-ietf-roll-unaware-leaves here, so some of
these comments can be saved for later. ;-)]

Needless to say, I don't like this approach.  But if the WG wants to
go forward this way, then I want to make this document Normatively
depend on draft-ietf-roll-unaware-leaves because that is where the
registry and meaning for the Status values are defined.  I also think
that because of that, we will want to hold sending this document back
to the RFC Editor until we get the final text for
draft-ietf-roll-unaware-leaves (and decide that we don't need
additional review for this document).

One more thing, in reading through rfc8505, I found this text (which I
had completely missed before):

   If the receiver of the message has registration state corresponding
to the related address, it SHOULD propagate the status down the
forwarding path to the Registered Node (e.g., reversing an existing
RPL [RFC6550] path as prescribed in [Efficient-NPDAO]).

So...if the rfc8505 status is "moved" (which is actually the topic of
the paragraph from where the text above was taken in §5.7), what
should be propagated using the DCO?  130?  Where is that specified?

> > [major] "the RPL Status MUST NOT be changed...is informative and does not
> > affect the behavior of the receiver...unknown values are ignored...Only
> > Rejection Codes (values of 128 and above) are expected in a DCO."
> >
> > If the value doesn't matter (informative) and unknown ones are ignored, why
> > specify that it MUST NOT change? What is the Normative value of that?
> > Specifically, if the value was changed to something < 128, what should the
> > receiver do?
>
> We wish the information to be known by all nodes, and this is a provision
> that we can reliably act differently per status value all the along the DODAG
> in the future. So we see this as protecting the future. Is that a problem?

Sorry...let me try again.  I see two problems:

(1) The values are informative, but Normatively are not to change.
How can the "MUST NOT" be enforced in the network?  How would a
receiver know if the value was changed (or not)?  You added that "we
can reliably act differently per status value" (but the text currently
reads: "value is informative and does not affect the behavior of the
receiver") -- having a consistent/reliable behavior can be achieved
only if it can be guaranteed that the value didn't change.  If it did
change, what is the expected behavior?

(2) If only values > 128 are expected, then what should a receiver do
if a value < 128 is received?  Should the DCO not be propagated
further?

> > opportunity to indicate these known reasons as Status in the DCO.  Among
> > other things, the target node would be able to identify the reason for the
> > unsolicited DCO...
>

Perfect!

Thanks!

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Oct 2019 18:07:30 +0000

Hello Alvaro : )

Please see below

> > When the address moves on the backbone, the RPL state in the old DODAG
> > is Cleaned from the 6LBR down. And the status from 6BBR to 6LBR is
> > moved so the expectation is that it percolates down. The rejection is
> > mostly to cleanup RPL since the leaf is expected to be long gone and
> > registered in a different DODAG across the backbone.
> 
> (1) the values are not the same...for example, "moved" in rfc8505 has a value
> of 3, not 130.  Why not use the same value?  The answer to this question
> overflows into my second concern...

It cannot be a convergence because RPL had rules in https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the status below 128 are warning. 
That provision was not really used so far to my best knowledge. So we could drop it. We chose not to so far. Could be done though if that's your recommendation.

> 
> (2) draft-ietf-roll-unaware-leaves doesn't update the allocation guidelines
> from rfc6550 (§6.5.1) for the Status, which then lands "moved" in the
> "Rejection" range.  IOW, the meaning is changed, but the original meaning of
> the DAO-ACK Status is not updated...
> 
> [We are not reviewing draft-ietf-roll-unaware-leaves here, so some of these
> comments can be saved for later. ;-)]

I see: we need to indicate that we update/extend the semantics of a the DAO-ACK status.
Should that be indicated in npdao draft or in unaware leaves, where the IANA is done for all?

> 
> Needless to say, I don't like this approach.  

What would your recommendation be? The need is to transport the 6LoWPAN status back in DAO-ACK and DAR messages.
The whole game is to divide the amount of recurrent messages by 2, by implicitly transport the periodic ND DAR in a periodic RPL DAO.
The DAO-ACK is pretty small and pretty full already so stealing the leftover bits to transport both separately seems difficult.

>                                                                                      But if the WG wants to go
> forward this way, then I want to make this document Normatively depend on
> draft-ietf-roll-unaware-leaves because that is where the registry and
> meaning for the Status values are defined.  I also think that because of that,
> we will want to hold sending this document back to the RFC Editor until we
> get the final text for draft-ietf-roll-unaware-leaves (and decide that we don't
> need additional review for this document).
 
That works for me, we can speed up unaware-leaves, it is mostly done.

> 
> One more thing, in reading through rfc8505, I found this text (which I had
> completely missed before):
> 
>    If the receiver of the message has registration state corresponding to the
> related address, it SHOULD propagate the status down the forwarding path
> to the Registered Node (e.g., reversing an existing RPL [RFC6550] path as
> prescribed in [Efficient-NPDAO]).
> 
> So...if the rfc8505 status is "moved" (which is actually the topic of the
> paragraph from where the text above was taken in §5.7), what should be
> propagated using the DCO?  130?  Where is that specified?
> 

We are specifying it right now in Efficient-NPDAO. RFC 8505 was forward looking to that respect. It had to indicate the ND status for that case and that status is "moved".
- It means the guys was down there but is no more. Which is exactly the topic of NPDAA, cleanup a downwards path that leads to a location from which the target has moved away.
- But it could not discuss how RPL translates it back and forth. The generic spec for that is unaware-leaves. DCO is a special case of RC/status that matches "moved" in RFC 8505.

> 
> > > [major] "the RPL Status MUST NOT be changed...is informative and
> > > does not affect the behavior of the receiver...unknown values are
> > > ignored...Only Rejection Codes (values of 128 and above) are expected in
> a DCO."
> > >
> value of that?

Because in some cases it will be turned into ND again and in those cases the meaning must be conveyed unmodified. NPDAO is the only vector we have in storing mode to convey something all the way down since the DAO-ACK is one hop.

> > > Specifically, if the value was changed to something < 128, what
> > > should the receiver do?
> >
> > We wish the information to be known by all nodes, and this is a
> > provision that we can reliably act differently per status value all
> > the along the DODAG in the future. So we see this as protecting the future.
> Is that a problem?
> 
> receiver know if the value was changed (or not)?  You added that "we can
> reliably act differently per status value" (but the text currently
> receiver") -- having a consistent/reliable behavior can be achieved only if it
> can be guaranteed that the value didn't change.  If it did change, what is the
> expected behavior?

The meaning we wanted to convey is that when propagating down the DCO, the status from the parent MUST be repeated unchanged to the children.
Suggestion to reword from the perspective of the intermediate router.

> (2) If only values > 128 are expected, then what should a receiver do if a
> value < 128 is received?  Should the DCO not be propagated further?

Yes, the DCO should be propagated and as done today, it causes the destruction of the path regardless of the value of the status, even a warning <128.
Should we change that so a warning is propagated but the route is conserved or something? There is no known usage of that today, does that protect the future better?

> > Agreed, let's look at this.

Cool, we'll propose text for all the above once we agree on the other points.

Enjoy the week end!

PAscal

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 28 Oct 2019 12:52:10 -0700

On October 25, 2019 at 2:08:48 PM, Pascal Thubert wrote:

Pascal:

Hi!

> > (1) the values are not the same...for example, "moved" in rfc8505 has a
> > value of 3, not 130. Why not use the same value? The answer to this question
> It cannot be a convergence because RPL had rules in
> https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the status below
> 128 are warning.
> That provision was not really used so far to my best knowledge. So we could
> drop it. We chose not to so far. Could be done though if that's your
> recommendation.

I think that would be a lot clearer...but that is a decision that the
WG needs to make.

> Should that be indicated in npdao draft or in unaware leaves, where the IANA

If the IANA update is to be done in draft-ietf-roll-unaware-leaves,
then there (that is part of the reason for the Normative dependence
below).

> > Needless to say, I don't like this approach.

To be clear, what I don't like is the fact that message that seem to
be intended for different things (ND, DAO-ACK, DCO) share the same
status information...and that it is not consistently corresponding
(the same values don't mean the same things...)....so while
homogenizing is a good thing, we seem to (currently) only go half way.

> The whole game is to divide the amount of recurrent messages by 2, by
> implicitly transport the periodic ND DAR in a periodic RPL DAO.
> The DAO-ACK is pretty small and pretty full already so stealing the leftover
> bits to transport both separately seems difficult.
>
> > meaning for the Status values are defined. I also think that because of
> > that, we will want to hold sending this document back to the RFC Editor
> > until we get the final text for draft-ietf-roll-unaware-leaves (and decide
> > that we don't need additional review for this document).
>
> We are specifying it right now in Efficient-NPDAO. RFC 8505 was forward
> looking to that respect. It had to indicate the ND status for that case and
> that status is "moved".
> - It means the guys was down there but is no more. Which is exactly the topic
> of NPDAA, cleanup a downwards path that leads to a location from which the
> target has moved away.
> - But it could not discuss how RPL translates it back and forth. The generic
> spec for that is unaware-leaves. DCO is a special case of RC/status that
> matches "moved" in RFC 8505.

Ok...so this piece is also dependent on
draft-ietf-roll-unaware-leaves.  I expect then clear pointers from
draft-ietf-roll-efficient-npdao to it.

> Because in some cases it will be turned into ND again and in those cases the
> meaning must be conveyed unmodified. NPDAO is the only vector we have in
> storing mode to convey something all the way down since the DAO-ACK is one
> hop.
>

...
> > receiver") -- having a consistent/reliable behavior can be achieved only if
> > it can be guaranteed that the value didn't change. If it did change, what
> > is the expected behavior?
>
> The meaning we wanted to convey is that when propagating down the DCO, the
> status from the parent MUST be repeated unchanged to the children.

Yes, I understand.

My question is from the Normative point of view.  The rfc2119 keywords
"MUST only be used where it is actually required for interoperation".
If informative, then we don't need "MUST NOT"...but if there is a
behavior expectation (or as you wrote above: "be turned into ND again
and in those cases the meaning must be conveyed unmodified"), then the
required behavior should be able to be verified somehow...and,
ideally, the specification should include an indication of what the
behavior should be if the mandatory action is not met.  We can of
course trust that nodes will follow the specification and will not
change the contents of the status...

So..I would like to see a couple of things:

(1) A clear indication of whether specific behavior is expected (you
have mentioned it twice in this thread, but the document doesn't
reflect that) or not based on the status.

(2) Text (maybe in the security considerations) pointing out the
effect of, changing the value in-flight, and how (if possible) to
mitigate it.

> Yes, the DCO should be propagated and as done today, it causes the
> destruction of the path regardless of the value of the status, even a warning
> <128.
> Should we change that so a warning is propagated but the route is conserved
> or something? There is no known usage of that today, does that protect the
> future better?

Going back to the text, which reads: "Only Rejection Codes (values of
128 and above) are expected in a DCO."  Also, going back to your
statements above about specific behavior resulting from the status
value.  I just want to make sure the specification is clear related to
what should be done; if any value is ok, then the text is, at minimum
not clear...if the behavior depends on the value, then there's an
effect if the value is not that is expected...

I hope we're making progress.  If not, we might want to think about
speaking live. :-)

Thanks!

Alvaro.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Oct 2019 09:51:50 +0000

.
> > That provision was not really used so far to my best knowledge. So we
> > could drop it. We chose not to so far. Could be done though if that's
> > your recommendation.
> 
> I think that would be a lot clearer...but that is a decision that the WG needs to
> make.
> 
> 

Maybe we could restructure the RPL Status with the first 2 bits becoming significant as opposed to the first bit only.

Today:

Bit 0 set  => error
Bits 1->7 => status code

Proposed change:

Bit 0 set  => means error ( 0 is warning or OK)
Bit 1 set  => transporting ARO status (refers to RFC 8505 and updates for definition off the next status)
Bits 2->7 => status code | ARO status depending on bit 1

> > > [We are not reviewing draft-ietf-roll-unaware-leaves here, so some
> > > of these comments can be saved for later. ;-)]
> >
> If the IANA update is to be done in draft-ietf-roll-unaware-leaves, then there
> (that is part of the reason for the Normative dependence below).

I'm good with that. Considering the stage of this doc, I'd rather not change it too much and do the above in the RUL draft.
We can complete the RUL draft quite quickly now,  and ship this useofrplinfo and RUL together.
 
> To be clear, what I don't like is the fact that message that seem to be intended
> for different things (ND, DAO-ACK, DCO) share the same status
> information...and that it is not consistently corresponding (the same values
> don't mean the same things...)....so while homogenizing is a good thing, we
> seem to (currently) only go half way.
> 

This is really helpful, Alvaro.
I read the whole answer once before starting to answer and the proposal above is what I found to meet this and the below.

> > We are specifying it right now in Efficient-NPDAO. RFC 8505 was
> > forward looking to that respect. It had to indicate the ND status for
> > that case and that status is "moved".
> > - It means the guys was down there but is no more. Which is exactly
> > the topic of NPDAA, cleanup a downwards path that leads to a location
> > from which the target has moved away.
> > - But it could not discuss how RPL translates it back and forth. The
> > generic spec for that is unaware-leaves. DCO is a special case of
> > RC/status that matches "moved" in RFC 8505.
> 
> draft-ietf-roll-unaware-leaves.  I expect then clear pointers from draft-ietf-roll-
> efficient-npdao to it.
> 
> 

Certainly

> > The meaning we wanted to convey is that when propagating down the DCO,
> > the status from the parent MUST be repeated unchanged to the children.
> 
> Yes, I understand.
> 
> If informative, then we don't need "MUST NOT"...but if there is a behavior
> expectation (or as you wrote above: "be turned into ND again and in those cases
> the meaning must be conveyed unmodified"), then the required behavior
> should be able to be verified somehow...and, ideally, the specification should
> include an indication of what the behavior should be if the mandatory action is
> not met.  We can of course trust that nodes will follow the specification and will
> not change the contents of the status...
> 
> (1) A clear indication of whether specific behavior is expected (you have
> mentioned it twice in this thread, but the document doesn't reflect that) or not
> based on the status.

Will do

> 
> (2) Text (maybe in the security considerations) pointing out the effect of,
> changing the value in-flight, and how (if possible) to mitigate it.
 
Same here. Note that I do not have a mitigation in mind right now.

> > > (2) If only values > 128 are expected, then what should a receiver
> > > do if a value < 128 is received? Should the DCO not be propagated further?
> >
> > destruction of the path regardless of the value of the status, even a
> > warning <128.
> > Should we change that so a warning is propagated but the route is
> > conserved or something? There is no known usage of that today, does
> > that protect the future better?
> 
> 128 and above) are expected in a DCO."  Also, going back to your statements
> above about specific behavior resulting from the status value.  I just want to
> make sure the specification is clear related to what should be done; if any value
> is ok, then the text is, at minimum not clear...if the behavior depends on the
> value, then there's an effect if the value is not that is expected...
> 

That text goes away if you agree with the proposal of the additional bit in the RPL status. The new text would say that "the ARO status MUST be placed unchanged by the root" in the mapped DCO with the bit ARO set. Conversely that the "6LR MUST place the mapped ARO status in the NA(ARO) that is built upon the DCO". 

RPL already has text like "
                  The root of a DODAG is
   authoritative for setting that information and the information is
   unchanged as propagated down the DODAG.
"

We can emulate that form for the DCO, say that "The root or common parent that generates a DCO is authoritative for setting the status information and the information is unchanged as propagated down the DODAG. " The transported ARO status is just a case of that. We'd also say that "this spec does not specify a differentiated action based on the status."

> 
> I hope we're making progress.  If not, we might want to think about speaking
> live. :-)

We are. If you agree with the proposed line above I'll make editions and come back to you for more comments and/or approval.

This is all very much appreciated, Alvaro.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Oct 2019 17:22:17 +0000

Dear all

More on the proposal below:

The proposal is to place more details in the RPL status in the RUL draft and make it a normative ref to efficient NPDAO. 

Changes in the efficient NPDAO draft:
====================

- Make the RUL draft a normative reference

- new description of the status:
"
   RPL Status: As defined in [RFC6550] and updated in
   [I-D.ietf-roll-unaware-leaves].  The root or common parent that
   generates a DCO is authoritative for setting the status information
   and the information is unchanged as propagated down the DODAG.  This
   document does not specify a differentiated action based on the RPL
   status.
"

Changes in the RUL draft:
====================

- In 4.  Updating RFC 6550, add:

"
   The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
   DAO-Ack message is extended to be used in the DCO messages
   [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
   to use a RPL status to transport the IPv6 ND status defined for use
   in the EARO, more in Section 7.
"

- Create a section 7 as:

"
7.  Updated RPL Status

   The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
   the DAO-Ack message and values are assigned as follows:

                  +---------+---------------------------+
                  | Range   | Meaning                   |
                  +=========+===========================+
                  | 0       | RFC 6550                  |
                  +---------+---------------------------+
                  | 1-127   | Not an outright rejection |
                  +---------+---------------------------+
                  | 128-255 | Rejection                 |
                  +---------+---------------------------+

                      Table 1: RPL Status per RFC 6550

   This specification extends the scope of the RPL status to be used in
   RPL DCO messages.  Furthermore, this specification enables to carry
   the status values defined for use in the IPv6 ND Extended Address
   Registration Option (EARO) and listed in table 1 of [RFC8505].  Only
   EARO status values in the range 0-63 can be transported.  The
   resulting RPL status is as follows:

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |E|A|  Value    |
      +-+-+-+-+-+-+-+-+

   RPL Status subfields:

   E:  1-bit flag.  Set to indicate a rejection.  When not set, A value
      of 0 indicates success.  Other values are non-rejection as per RFC
      6550.

   A:  1-bit flag.  Set to indicate the type of the status value.

   Value:  6-bit unsigned integer.  If the 'E' flag is set this field
      transports a status value defined for IPv6 ND EARO.  When the 'E'
      flag is reset, the status value is defined in a RPL extension

   When building a DCO message upon an IPv6 ND NA or DAC message, the
   root MUST place the ARO status unchanged in a mapped DCO with the 'A'
   bit set.  Conversely the 6LR MUST place the ARO status unchanged in
   the NA(EARO) that is built upon a DCO with the 'A' bit set.

"

- Remove section 12.2 since we do not create new status values, we now transport the ARO status as defined by ND.

- Instead, create the missing registries that RFC 6550 did not as
"

13.2.  New Subregistry for the RPL Non-Rejection Status values

   This specification creates a new subregistry for the RPL Non-
   Rejection Status values for use in RPL DAO-ACK and RCO Messages,
   under the ICMPv6 parameters registry.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  Initial allocation is as indicated in Table 2:

            +-------+------------------------+---------------+
            | Value | Meaning                | Defining Spec |
            +=======+========================+===============+
            | 0     | Unqualified acceptance | RFC 6550      |
            +-------+------------------------+---------------+

            Table 2: Status values of the RPL DAO-ACK Message

13.3.  New Subregistry for the RPL Rejection Status values

   This specification creates a new subregistry for the RPL Non-
   Rejection Status values for use in RPL DAO-ACK and RCO Messages,
   under the ICMPv6 parameters registry.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  There is no initial allocation
"

Fire at will!

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 29 octobre 2019 10:52
> To: 'Alvaro Retana' <[email-masked]>; draft-ietf-roll-efficient-
> [email-masked]
> Cc: [email-masked]; roll <[email-masked]>; Peter van der Stok
> <[email-masked]>
> Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16
> 
> .
> > >
> > > That provision was not really used so far to my best knowledge. So
> > > we could drop it. We chose not to so far. Could be done though if
> > > that's your recommendation.
> >
> Maybe we could restructure the RPL Status with the first 2 bits becoming
> significant as opposed to the first bit only.
> 
> Today:
> 
> Bit 0 set  => error
> Bits 1->7 => status code
> 
> Proposed change:
> 
> Bit 0 set  => means error ( 0 is warning or OK) Bit 1 set  => transporting ARO
> status (refers to RFC 8505 and updates for definition off the next status) Bits
> 2->7 => status code | ARO status depending on bit 1
> 
> >
> > then there (that is part of the reason for the Normative dependence below).
> 
> 
> I'm good with that. Considering the stage of this doc, I'd rather not change it
> too much and do the above in the RUL draft.
> I read the whole answer once before starting to answer and the proposal
> above is what I found to meet this and the below.
> 
> 
> > > forward looking to that respect. It had to indicate the ND status
> > > for that case and that status is "moved".
> > > the topic of NPDAA, cleanup a downwards path that leads to a
> > > location from which the target has moved away.
> > draft-ietf-roll- efficient-npdao to it.
> >
> >
> 
> Certainly
> 
> 
> > > The meaning we wanted to convey is that when propagating down the
> > > DCO, the status from the parent MUST be repeated unchanged to the
> children.
> >
> > Yes, I understand.
> >
> > course trust that nodes will follow the specification and will not change the
> contents of the status...
> >
> > effect of, changing the value in-flight, and how (if possible) to mitigate it.
> 
> > > destruction of the path regardless of the value of the status, even
> > > a warning <128.
> > not clear...if the behavior depends on the value, then there's an effect if the
> value is not that is expected...
> >
> 
> That text goes away if you agree with the proposal of the additional bit in the
> RPL status. The new text would say that "the ARO status MUST be placed
> unchanged by the root" in the mapped DCO with the bit ARO set. Conversely
> that the "6LR MUST place the mapped ARO status in the NA(ARO) that is built
> upon the DCO".
> 
> We can emulate that form for the DCO, say that "The root or common parent
> that generates a DCO is authoritative for setting the status information and
> the information is unchanged as propagated down the DODAG. " The
> transported ARO status is just a case of that. We'd also say that "this spec
> does not specify a differentiated action based on the status."
> 
> 
> >
> We are. If you agree with the proposed line above I'll make editions and come
> back to you for more comments and/or approval.
>

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 29 Oct 2019 15:09:54 -0700

Hi!

I’m fine with the changes proposed to draft-ietf-roll-efficient-npdao.

I want to see the WG reach consensus on the changes related
to draft-ietf-roll-unaware-leaves.

Thanks!

Alvaro.

On October 29, 2019 at 5:52:13 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

 If you agree with the proposed line above I'll make editions and come back
to you for more comments and/or approval.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Oct 2019 07:38:36 +0000

There was a typo, the proposed text in section 7 reads:

   RPL Status subfields:

   E:  1-bit flag.  Set to indicate a rejection.  When not set, a value
      of 0 indicates success and other values indicate an non-outright-
      rejection as per RFC 6550.

   A:  1-bit flag.  Indicates the type of the status value.

   Status Value:  6-bit unsigned integer.  If the 'A' flag is set this
      field transports a status value defined for IPv6 ND EARO.  When
      the 'A' flag is reset, the status value is defined in a RPL
      extension.

Voila!

Pascal
> From: Pascal Thubert (pthubert) <[email-masked]>
> Sent: mardi 29 octobre 2019 18:22
> To: Alvaro Retana <[email-masked]>; draft-ietf-roll-efficient-
> [email-masked]
> The proposal is to place more details in the RPL status in the RUL draft and
> make it a normative ref to efficient NPDAO.
> 
> - Remove section 12.2 since we do not create new status values, we now
> transport the ARO status as defined by ND.
> 
> - Instead, create the missing registries that RFC 6550 did not as "
> 
> > To: 'Alvaro Retana' <[email-masked]>;
> > draft-ietf-roll-efficient- [email-masked]
> > > I think that would be a lot clearer...but that is a decision that
> > > the WG needs to make.
> > >
> > >
> >
> >
> > Maybe we could restructure the RPL Status with the first 2 bits
> > becoming significant as opposed to the first bit only.
> >
> > Today:
> >
> > Bit 0 set  => error
> > Bits 1->7 => status code
> >
> > Proposed change:
> >
> > Bit 0 set  => means error ( 0 is warning or OK) Bit 1 set  =>
> > transporting ARO status (refers to RFC 8505 and updates for definition
> > off the next status) Bits
> > > > > guidelines from rfc6550 (§6.5.1) for the Status, which then
> > > > > lands "moved" in the "Rejection" range. IOW, the meaning is
> > > > > changed, but the original meaning of the DAO-ACK Status is not
> updated...
> > > > >
> > > > > [We are not reviewing draft-ietf-roll-unaware-leaves here, so
> > > > > some of these comments can be saved for later. ;-)]
> > > >
> > I'm good with that. Considering the stage of this doc, I'd rather not
> > change it too much and do the above in the RUL draft.
> > I read the whole answer once before starting to answer and the
> > proposal above is what I found to meet this and the below.
> >
> >
> > > > - It means the guys was down there but is no more. Which is
> > > > exactly the topic of NPDAA, cleanup a downwards path that leads to
> > > > a location from which the target has moved away.
> > > > - But it could not discuss how RPL translates it back and forth.
> > > > The generic spec for that is unaware-leaves. DCO is a special case
> > > > of RC/status that matches "moved" in RFC 8505.
> > >
> > > My question is from the Normative point of view.  The rfc2119
> > > keywords "MUST only be used where it is actually required for
> interoperation".
> > > behavior expectation (or as you wrote above: "be turned into ND
> > > again and in those cases the meaning must be conveyed unmodified"),
> > > then the required behavior should be able to be verified
> > > somehow...and, ideally, the specification should include an
> > > indication of what the behavior should be if the mandatory action is
> > > not met.  We can of course trust that nodes will follow the
> > > specification and will not change the
> > > > > (2) If only values > 128 are expected, then what should a
> > > > > receiver do if a value < 128 is received? Should the DCO not be
> > > > > propagated
> > further?
> > > >
> > > > destruction of the path regardless of the value of the status,
> > > > even a warning <128.
> > > > conserved or something? There is no known usage of that today,
> > > > does that protect the future better?
> > >
> > > value.  I just want to make sure the specification is clear related
> > > to what should be done; if any value is ok, then the text is, at
> > > minimum not clear...if the behavior depends on the value, then
> > > there's an effect if the
> > That text goes away if you agree with the proposal of the additional
> > bit in the RPL status. The new text would say that "the ARO status
> > MUST be placed unchanged by the root" in the mapped DCO with the bit
> > ARO set. Conversely that the "6LR MUST place the mapped ARO status in
> > the NA(ARO) that is built upon the DCO".
> >
> > We can emulate that form for the DCO, say that "The root or common
> > parent that generates a DCO is authoritative for setting the status
> > information and the information is unchanged as propagated down the
> > DODAG. " The transported ARO status is just a case of that. We'd also
> > say that "this spec does not specify a differentiated action based on the
> status."
> >
> >
> > >
> > We are. If you agree with the proposed line above I'll make editions
> > and come back to you for more comments and/or approval.
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Oct 2019 10:36:51 +0000

Dear all :

There is a need in the RUL draft to carry a 6LoWPAN ND status inside a RPL status so we can avoid duplicating DAR/DAC and DAO/DAO-ACK through the network. This also allows async communication down the DODAG through DCO (efficient NPDAO).

Alvaro pointed out that mapping one  status in the other as proposed so far was not too clean. The change proposed herein addresses this concern. The change would be adding another control bit in the RPL status and formalizing the format as follows:

7.  Updated RPL Status

   EARO status values in the range 0-63 can be transported.

   The resulting RPL status is as follows:

                        0 1 2 3 4 5 6 7
                      +-+-+-+-+-+-+-+-+
                       |E|A|  Value    |
                       +-+-+-+-+-+-+-+-+

                        Figure 2: RPL status Format

   RPL Status subfields:

      extension

Comments welcome (and urgent!). Unless I see opposition I plan to publish before cutoff so we can discuss it at IETF 106.

All the best;

Pascal

From: Alvaro Retana <[email-masked]>
Sent: mardi 29 octobre 2019 23:10
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: [email-masked]; roll <[email-masked]>; Peter van der Stok <[email-masked]>
Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16

Hi!

I want to see the WG reach consensus on the changes related to draft-ietf-roll-unaware-leaves.

Thanks!

Alvaro.

On October 29, 2019 at 5:52:13 AM, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:
 If you agree with the proposed line above I'll make editions and come back to you for more comments and/or approval.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 30 Oct 2019 08:43:04 -0700

Just for clarity.

The changes proposed here are for draft-ietf-roll-unaware-leaves
(not draft-ietf-roll-efficient-npdao).  I changed the subject to reflect
that.

Alvaro.

On October 30, 2019 at 6:37:15 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Dear all :

There is a need in the RUL draft to carry a 6LoWPAN ND status inside a RPL
status so we can avoid duplicating DAR/DAC and DAO/DAO-ACK through the
network. This also allows async communication down the DODAG through DCO
(efficient NPDAO).

Alvaro pointed out that mapping one  status in the other as proposed so far
was not too clean. The change proposed herein addresses this concern. The
change would be adding another control bit in the RPL status and
formalizing the format as follows:

7.  Updated RPL Status

                  | Range   | Meaning                   |

                  | 0       | RFC 6550                  |

                  | 128-255 | Rejection                 |

                        0 1 2 3 4 5 6 7

                      +-+-+-+-+-+-+-+-+

                       |E|A|  Value    |

                       +-+-+-+-+-+-+-+-+

   RPL Status subfields:

      extension

Comments welcome (and urgent!). Unless I see opposition I plan to publish
before cutoff so we can discuss it at IETF 106.

All the best;

Pascal

*From:* Alvaro Retana <[email-masked]>
*Sent:* mardi 29 octobre 2019 23:10
*To:* Pascal Thubert (pthubert) <[email-masked]>;
[email-masked]
*Cc:* [email-masked]; roll <[email-masked]>; Peter van der Stok <
[email-masked]>
*Subject:* RE: AD Review of draft-ietf-roll-efficient-npdao-16

Hi!

Thanks!

Alvaro.

---

From: Ines Robles <[email-masked]>
Date: Thu, 31 Oct 2019 13:57:02 +0200

Hi Pascal,

Agree with the status codes.

Questions:

1- In the  Table 1: RPL Status per RFC 6550, when the status is zero, would
it be good to add between  brackets (Success/Unqualified acceptance -since
you mentioned it when explaining bit E -) like: ,

                  | Range   | Meaning                   |

                  | 0       | RFC 6550 (Success)        |

2- where states "...When the 'A' flag is reset," should it be better "When the
'A' flag is not set," ?

Thank you,

Ines.

On Wed, Oct 30, 2019 at 5:43 PM Alvaro Retana <[email-masked]>
wrote:

> Alvaro pointed out that mapping one  status in the other as proposed so
> far was not too clean. The change proposed herein addresses this concern.
> The change would be adding another control bit in the RPL status and
>  If you agree with the proposed line above I'll make editions and come
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 31 Oct 2019 13:53:54 +0000

I made the suggested changes Ines, many thanks!

Pascal

From: Ines Robles <[email-masked]>
Sent: jeudi 31 octobre 2019 12:57
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>
Subject: Re: [Roll] draft-ietf-roll-unaware-leaves (WAS: AD Review of draft-ietf-roll-efficient-npdao-16)

Hi Pascal,

Questions:

1- In the  Table 1: RPL Status per RFC 6550, when the status is zero, would it be good to add between  brackets (Success/Unqualified acceptance -since you mentioned it when explaining bit E -) like: ,

2- where states "...When the 'A' flag is reset," should it be better "When the 'A' flag is not set," ?

Thank you,

Ines.

On Wed, Oct 30, 2019 at 5:43 PM Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
Just for clarity.

The changes proposed here are for draft-ietf-roll-unaware-leaves (not draft-ietf-roll-efficient-npdao).  I changed the subject to reflect that.

Alvaro.

On October 30, 2019 at 6:37:15 AM, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:
Dear all :

7.  Updated RPL Status

                        0 1 2 3 4 5 6 7
                      +-+-+-+-+-+-+-+-+
                       |E|A|  Value    |
                       +-+-+-+-+-+-+-+-+

   RPL Status subfields:

All the best;

Pascal

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Sent: mardi 29 octobre 2019 23:10
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; roll <[email-masked]<mailto:[email-masked]>>; Peter van der Stok <[email-masked]<mailto:[email-masked]>>
Subject: RE: AD Review of draft-ietf-roll-efficient-npdao-16

Hi!

Thanks!

Alvaro.

[email-masked]<mailto:[email-masked]>