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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jul 2021 14:13:23 +0000

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

---

From: Ines Robles <[email-masked]>
Date: Tue, 13 Jul 2021 20:14:20 +0300

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=
[email-masked]> 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:
>
> > 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.
> > 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 "
> I'd read this as: Additional metrics used for routing decision -
> indirectly, via the Rank computation by the OF
> > 4) resource calculations "but how the root figures the amount of
> resources that are available is out of 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.
>
> 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
>
> > 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!
>
> > 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
>
>
> > 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.
>
>
> > 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.
>
>
> > 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?
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>