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

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

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

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

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

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?

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


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

Enjoy the week end!

PAscal
> 
> Thanks!
> 
> Alvaro.