Subject: Re: [Roll] call for adoption of dao-projection draft

From: Satish Anamalamudi <[email-masked]>
Date: Tue, 6 Dec 2016 03:01:10 +0000

Hello all,

I support this draft for adoption. 

This draft proposal is significant to minimize the “routing control message overhead” in non-storing mode through loose source routing for down-stream data transmission. 

With regards,
Satish.
-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 2016年11月24日 17:52
To: [email-masked]; Routing Over Low power and Lossy networks
Subject: Re: [Roll] call for adoption of dao-projection draft

As author I support it to enable a routing computation from a central PCE. This type is deployment is common in the industry, and should be considered in IETF standards.

Cheers,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: lundi 21 novembre 2016 12:51
To: Roll <[email-masked]>
Subject: Re: [Roll] call for adoption of dao-projection draft

(hat off)

I support this work because it provides an interesting technology to shorten node to node paths in non-storing mode.

Peter

peter van der Stok schreef op 2016-11-21 12:25:
> Dear all,
> 
> (This is the call for adoption for the *dao-projection* document.)
> 
> During the Wednesday meeting of the WG, we've discussed three drafts, 
> which address items we have in our charter. We've had three 
> raise-of-hands in the room, with support for the adoption of the 
> documents. You can find the minutes at the following address:
> https://datatracker.ietf.org/doc/minutes-97-roll/
> 
> We are now moving the call for adoption to the mailing list and will 
> be closing the call in two weeks (on December 6th, 2016).
> 
> This is the call for adoption for " Root initiated routing state in 
> RPL" draft-thubert-roll-dao-projection-03
> 
> Please read the draft and reply to the list with your comments, 
> remarks, suggestions and votes on the adoption of this document.
> 
> Many thanks for your reaction,
> 
> Ines and Peter
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Wed, 07 Dec 2016 12:20:18 +0100

Dear all

This call for adoption is closed.
Given the positive reactions on the mailing list we are happy to adopt 
this draft as a WG document.
Can the authors please re-submit as an ietf-roll-title draft

Greetings,

Ines and Peter

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Dec 2016 12:02:22 -0500

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 absense of a Configuration
option.

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

3) does dao-lifetime eclipse need for no path dao?

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.

5) section 4 needs subsections! Too many concepts in one heading.

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?

7) page 8 is too dense!

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

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.

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?

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.

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.

13) Q: retransmission timers, etc. appropriate for these projected DAO messages?
    How do we handle packet loss?

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?

======== START of EDITORIAL comments

Change:
   Additionally, RPL storing mode is optimized or Point-to-Multipoint
   (P2MP), root to leaves and Multipoint-to-Point (MP2P) leaves to root
   operations, whereby routes are always installed along the RPL DODAG.

To:
   Additionally, RPL storing mode is optimized for Point-to-Multipoint
   (P2MP), (..root to leaves and Multipoint-to-Point (MP2P) leaves to root
   operations), whereby routes are always installed along the RPL DODAG.

the part () is worded too poorly for me to parse.  Can you fix this?

   Transversal Peer to Peer (P2P) routes in a RPL network will generally
   suffer from some stretch since routing between 2 peers always happens

What means "stretch" here?

section 2: NSM -- I think this is a new term?
        (it's not in RFC6550 or 7102. I'm all for this term)

section 3: I found the comments about factoring to be too soon.
        Some explanation of mechanism should preceed this part of the
        discussion.  Just let section 3 be about the formats/contents.

I suggest text like this:
  In NSM the TIO option is used in the DAO message to indicate the immediate
  parent of a given path.  The TIO applies to the Target options that
  immedially preceed it, and multiple TIOs may be present to indicate
  multiple routes.

  This specification...

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-