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

[Alvaro Retana <[e-mail]>]

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

Pascal:

Hi!


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

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



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

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.


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

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.



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

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

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.



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

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.