Re: [Roll] Open issues from Michael's late response at adoption call

[Ines Robles <[e-mail]>]

Thank you very much Pascal for addressing the open issues. We would like to
have one or two deep reviews before WGLC.

Dear all, please let us know if you can perform a review to dao-projection
draft by 23th July.

Thank you very much in advance,

Ines.

On Mon, Jul 12, 2021 at 5:18 PM Pascal Thubert (pthubert) <pthubert=
[e-mail]> wrote:

> Dear all
>
> Ines pointed out an active ticket
> https://trac.ietf.org/trac/roll/ticket/179 and
> https://trac.ietf.org/trac/roll/ticket/180 against the DAO projection
> draft. It was logged at adoption call time and I failed to respond
> properly.
>
> This was against
> https://datatracker.ietf.org/doc/html/draft-thubert-roll-dao-projection-03
> , water under the bridge so I tried to sort things out and published
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-18
> as a result.
>
> In more details:
>
> > Michael Richardson wrote on 12-24-2016
> > Hi, I had intended to finish this as part of the adoption call, having
> previously read the document, but was late.  These comments are probably
> more useful now anyway.  I can open tickets as appropriate if chairs
> direct.
> > Let me leave editorial comments to the end of this email.
>
>
> > 1) Didn't we have an errata about default lifetime units when there was
> no configuration option?
> > No, we didn't.  I wonder if this plagues us everywhere, that 6550 should
> have specified a default Lifetime units in the absence of a Configuration
> option.
>
> I think that was by design. RPL can be used in a great many environments
> with lots of diversity, from high speed wires in ANIMA to 2Kps LLNs. Couple
> that with any size of netwoks, with cases of ~10K sometimes. A default
> value can be programmed for a particular use case, say Wi-SUN, and in that
> case the SDO that leverages RPL will define it for its own purpose.
>
> > 2) http://tools.ietf.org/html/rfc6551 reference:  "or the RPL routing
> extensions specified in Routing for Path Calculation in LLNs [RFC6551].
> Based on that information, the root "
> > huh? the title of 6551 is: Routing Metrics Used for Path Calculation in
> Low-Power and Lossy Networks
> > so, what exactly did you mean here?
>
> I'd read this as: Additional metrics used for routing decision -
> indirectly, via the Rank computation by the OF
> But then I could not find that text in early or current versions, so I
> guess this issue disappeared?
>
>
> > 3) does dao-lifetime eclipse need for no path dao?
>
> Same as main RPL. Some users might let the route die if signaling is
> expensive.
>
> > 4) resource calculations "but how the root figures the amount of
> resources that are available is out of scope."
> > I disagree. I would like some mechanism to be in scope.
> > And you suggest NMS and 6551 later on... which seems to make it in
> scope. I'm not sure how 6551 can be used here.
>
> We agree. The capabilities draft will do that when we find time to work on
> it.
>
> > 5) section 4 needs subsections! Too many concepts in one heading.
>
> This was " 4.  Loose Source Routing in Non-storing Mode ". It is now "
> A.1.  Loose Source Routing " only 4 paragraphs. The rest was spread as
> suggested
>
> > 6) On the use of a new MOP.
> > Are we sure that we need a new MOP?  Could we use Non-Storing MOP, with
> some indication of which nodes speak DAO-Projection?  Could that work?
> > Or do you really want to force a forklift upgrade here? Why does the
> entire network need to be aware of this new mode?
>
> Agreed, this is gone now
>
> > 7) page 8 is too dense!
>
> Was split and expanded. I consider that fixed
>
> > 8) I just didn't understand the english here.
> > I think that "last node" needs a better term.  Maybe colour the nodes or
> otherwise mark them and use those terms?
> > The last node in the segment may have another information to reach the
> target(s), such as a connected route or an already installed projected
> route.  If it does not have such a route then the node
>
> This is gone
>
>
> > 9) running out of resources:
> > it seems that it ought to be said that the new node might not be one
> that the last node had previously talked to.  There is the issue of both
> routing storage (from storing mode), but also neighbor cache resources.
>
> Can't find the related text in any version. But the neighbor cache is
> created before the sibling is advertised, so the lack of it os not found at
> route creation time.
>
>
> > 10) more hard to understand statements...
> > For the targets that could be located, last node in the segment
> generates a DAO to its loose predecessor in the segment as indicated in the
> list of Via Information options.
> > woe!  What?
>
> I hope the explanation is better now. The storing mode DAO flows from
> egress to ingress as a the normal DAO flows from leaf to root.
>
>
> > 11) create new section on route cleanup
> > A NULL lifetime in the Via Information option along the segment is used
> to clean up the state.
> > needs new 4.x section on cleanup.
>
> Please see "7.3.1.  Storing-Mode P-Route" in -18. I split as suggested
>
> > 12) move / replicate diagrams into this section, and use numbered
> diagrams
> > In the example below, say that there is a lot of traffic to nodes 55
> > new section, move diagram here.
> > make figure 5 and 6 more like figure 3, numbered, etc.
>
> done
>
> > 13) Q: retransmission timers, etc. appropriate for these projected DAO
> messages?
> > How do we handle packet loss?
>
> Added text
> "
>      The process continues till the P-DAO is propagated to ingress router
> of
>      the Segment, which answers with a DAO-ACK to the Root. The Root
> always
>      expects a DAO-ACK, either from the Track Ingress with a positive
> status
>      or from any node along the segment with a negative status. If the
> DAO-ACK
>      is not received, the Root may retry the DAO with the same TID, or tear
>      down the route.
> "
>
>
>
> > 14) Security Considerations will need to be written.
> > The security threats documents details very specific threats, and
> indicating if this protocol changes things is important.  Also, some
> consideration SHOULD be given to when A=1.  Are the affects of the new flow
> of control messages?
> > So for instance Security Considerations should probably consider how
> projected DAO messages could be abused by
> > a) rogue nodes b) via replay of messages c) if use of projected DAO
> messages could in fact deal with any threats?
>
> I created a security section in line with that of RFC 9010.
>
> I hope and believe that this removes the road block to go for last call.
>
> You all keep safe!
>
> Pascal
>
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>