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

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

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