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

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

Hello Alvaro:


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

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

Is there a strong reason for the reuse?


<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

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

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