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

[Alvaro Retana <[e-mail]>]

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

Pascal:

Hi!

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


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

Perfect!

Thanks!

Alvaro.