Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00

[Mukul Goyal <[e-mail]>]

Hi JP

>6) We just need to have a section somewhere indicating that such reactive mechanism has a cost too and the resulting
path cost decrease is not known a priori and may end up being close to the DAG cost for that destination. I am not
questioning the usefulness of the mechanism, just make sure to indicate it.


>I can help provide some text, if that helps.

Sure, please send me the text you would like to see in the draft. Also, I wanted to point out that the purpose of the measurement messages is to help decide whether to initiate a reactive route discovery ot not. If the measurement of the cost of an existing (DAG-based) route indicates that this route is good enough, there wont be a need to do a reactive discovery. Further, the "good enough" criteria can be selected on the basis of information provided by measurement messages. If the measurement on a DAG-based route returns an end-to-end cost "x", the good enough criteria can be set to some fraction of x thereby ensuring that any discovered P2P routes have a certain minimum cost advantage over DAG-based route. Ofcourse, there may not exist any P2P routes with such advantage (and that's why we need to put in the text that you are suggesting).

Thanks
Mukul
  

----- Original Message -----
From: "JP Vasseur" <[e-mail]>
To: "Anders Brandt" <[e-mail]>
Cc: "Mukul Goyal" <[e-mail]>, "roll" <[e-mail]>
Sent: Tuesday, May 18, 2010 11:01:57 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00

Hi Anders, 



On May 17, 2010, at 4:18 PM, Anders Brandt wrote: 




Hi JP 
  



Please find comments inline 

  
- Anders 
  




From: JP Vasseur [ mailto:[e-mail] ] 
Sent: Monday, May 17, 2010 15:05 
To: Anders Brandt; Mukul Goyal 
Cc: roll 
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 


Hi Anders, 


Co-chair hat-off. 


I think that it goes in right direction. 


Few comments for the moment. 


1)  o The constraint to route only along a DAG leading to significantly suboptimal P2P routes and traffic congestion near the DAG root. 
JP> You may want to soften the statement here since the path computed along the DAG  
may be sub-optimal .. it all depends on the destination, degree of meshing of the DAG, etc ... 
I think that the argument of not having to maintain route maintenance for some nodes is  
more compelling.   
  


What about: 
"The constraint to route only along a DAG potentially leading to significantly 
suboptimal P2P routes and traffic congestion near the DAG root."   ? 

OK 






2)  Such applications require a mechanism for "reactive route discovery" and the ability to route "across DAGs". 


JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ?   
  
Agreed. What the text should say is: 
"across a DAG", "across the branches of a dag" or "along non-DAG routes"  (pick one)   


I would choose "non DAG route" 







3)  The mechanisms described in this document are intended to be employed as complementary to RPL in specific scenarios that need point-to-
   point (P2P) routes between arbitrary nodes. 


JP> More specifically, I think that we agree that it will be part of RPL, as an optional mechanism.   
  
Negative. 

RPL will never be able to deliver the required performance for home and 
building without decent support for battery operation and reactive self-healing. 


You misunderstood my point. The WG agreed that this was a MUST, I am not questioning the usefulness 
of it. I just meant to say that all implementations will not need it, that's all (thus the term optional). 








4) Section 4.2: objective function 


JP> You actually do not need an OF for that. Just use the metrics specified in the Routing-metrics ID, 
adding a path-cost-bound object (for the "good enough" criteria).   
  



Great. This is an example of why it will be valuable for RPL as a whole if the WG starts discussing 
how to achieve the stated goals of the draft. 
OF or metrics - I leave it for the experts to decide which is the right thing. As long as I can ask for a 
"good enough" route as result of a reactive discovery. I need the lamp to turn on with low delay. 
Later, I may have time for fine-tuning the route. 


We're in sync. 






  




5)  4.6. Transport of Routing Metrics The Metric Container option defined in RPL-07 can be used to carry
   both the aggregated end-to-end and the local values for the routing
   metrics being used to define the routing cost.  Additional metric
   objects may need to be defined to carry the aggregated end-to-end
   routing cost and a source-route unmodified from one node to another; 


JP> with regards to the second part of the paragraph I would suggest to use the same metrics as defined 
in the routing-metric ID. 


6) We just need to have a section somewhere indicating that such reactive mechanism has a cost too and the resulting 
path cost decrease is not known a priori and may end up being close to the DAG cost for that destination. I am not 
questioning the usefulness of the mechanism, just make sure to indicate it. 


I can help provide some text, if that helps. 


Thanks. 


JP. 





Thanks. 


JP. 


On May 17, 2010, at 9:28 AM, Anders Brandt wrote: 




Hi all 

The P2P draft has been out for some weeks now. 
The team would like to poll the WG for directions whether this is 
the right approach. 



Phil has indicated some agreement. 
What about the rest of the WG? 

Others in favour of the work? 
Any alternative proposals? 

Otherwise the P2P team will conclude that we are on the right track 
and go on proposing specific frame format additions/modifications 
and mechanisms for RPL. 
When the required maturity is reached, those proposed additions/changes 
should be adopted by the RPL spec; thus obsoleting this draft. 

Thanks, 
 Anders 




On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: 







Hi all 









The following draft has been submitted for WG's consideration. It 




describes the additional mechanisms required to support P2P 


routing in 




LLNs. The draft first provides a high level description of the 




mechanisms and then proposes one way of realizing these 


mechanisms in 




RPL. 









Regards 




Mukul 









----- Forwarded Message ----- 




From: "IETF I-D Submission Tool" < [e-mail] > 




To: [e-mail] 




Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada 




Central 




Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 














A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been 




successfully submitted by Mukul Goyal and posted to the IETF 




repository. 









Filename: draft-dt-roll-p2p-rpl 




Revision: 00 




Title: Mechanisms to Support Point-to-Point 


Routing in Low Power   




and Lossy Networks 




Creation_date: 2010-04-28 




WG ID: Independent Submission 




Number_of_pages: 13 









Abstract: 




This draft presents mechanisms to determine the end-to-end 


cost of an 




existing route and to discover/establish "on demand" one or more 




routes between two nodes in a low power and lossy network.   


This draft 




also proposes functionality that would enable RPL to 


provide these P2P 




mechanisms. 



















The IETF Secretariat. 














_______________________________________________ 




Roll mailing list 




[e-mail] 




https://www.ietf.org/mailman/listinfo/roll 





_______________________________________________ 


Roll mailing list 


[e-mail] 


https://www.ietf.org/mailman/listinfo/roll 



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