Subject: Re: [Roll] Moving forward with the protocol work

From: Mukul Goyal <[email-masked]>
Date: Fri, 31 Jul 2009 08:07:14 -0500 (CDT)

Pascal

OK. This puts all the arguments to rest. Me, Jerry and JP (who has been insisting again and again that ROLL has to provide good P2P solution) had been looking at the wrong WG all along. We should go bang the MANET WG door and ask for a good P2P routing solution for LLNs.

Thanks
Mukul
  
----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "d sturek" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "Jerald P Martocci" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, [email-masked]
Sent: Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] Moving forward with the protocol work

Hi Don:

I'm all with you here. Optimized P2P for all comes at a cost, in particular in terms of states in the nodes, and is clearly a secondary priority for ROLL. OTOH, in a use case where all nodes can really afford all the states involved, the problem seems to drift outside the ROLL charter and back in the MANET world.

ROLL does not compete with MANET and defers to the MANET work where it applies.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
>Sent: vendredi 31 juillet 2009 14:12
>To: 'Mukul Goyal'; 'Jerald P Martocci'
>Cc: 'ROLL WG'; [email-masked]
>Subject: Re: [Roll] Moving forward with the protocol work
>
>Hi Mukul,
>
>I don't agree that the alternate solutions proposed for ROLL scale and could support requirements outside
>building controls.  Specifically, I believe that the non-DAG solutions will require state information
>retention which will limit deployment beyond a modest number of nodes in the network.
>
>I believe the opposite as to what is proposed below.  I would propose using the RPL proposal as the baseline
>and provide some mechanisms to support optimization of P2P traffic.
>
>Best Regards,
>
>Don Sturek
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Mukul Goyal
>Sent: Friday, July 31, 2009 4:27 AM
>To: Jerald P Martocci
>Cc: ROLL WG; [email-masked]
>Subject: Re: [Roll] Moving forward with the protocol work
>
>I absolutely support the approach Jerry suggested:
>
>1) The foundation should be as simple as possible - a simple distance vector approach (I hope there is an
>agreement on this) describing next-hop selection based on routing metrics defined in the routing metrics
>draft, constraints and strategies (OCP) and basic rules to decide when to generate RAs. The foundation should
>not include any mechanism to deal with loops (so, it should not include DAGs unless DAGs can be shown to be
>critical in meeting other essential requirements).
>
>2) Additional document(s) suggesting solutions catered towards MP2P and/or P2P routing using different
>mechanisms to deal with loops (including DAGs).
>
>Thanks
>Mukul
>
>----- Original Message -----
>From: "Jerald P Martocci" <[email-masked]>
>To: "Zach Shelby" <[email-masked]>
>Cc: "Mukul Goyal" <[email-masked]>, "ROLL WG" <[email-masked]>, [email-masked]
>Sent: Thursday, July 30, 2009 3:59:30 PM GMT -06:00 US/Canada Central
>Subject: Re: [Roll] Moving forward with the protocol work
>
>
>
>Zach,
>
>When the design team was formed it stated its plan was to develop a core routing specification that met the
>needs of all the requirement specifications and then ancillary specifications to meet the specific needs for
>each of the requirements.  RPL as currently written seems perfectly suitable for the MP2P requirement, yet not
>too suitable for P2P requirement.  Could we repackage RPL so that its base spec contains only the generic
>routing requirements such as 1) using varied metrics to define path preferences, 2) OCP to advertise path
>strategy and 3) trickle to cleanly vary periodic requirements.  Then RPL-1 could be then enhancements for MP2P
>applications and would include the DAG.  This would allow us to define a different extension, RPL-2, for P2P
>requirements that need not be DAG based.
>
>JP has promised that if I just shut-up and give the DT some time, they will provide a solid P2P solution.  I
>am willing to do that.  However, I would hate to start compromising the MP2P solution to wedge in a sub-
>optimal P2P solution.  Maybe we can have our cake and eat it too if we simply repackage the specs a bit.
>
>Jerry
>
>
>
>
>Zach Shelby <[email-masked]>
>Sent by: [email-masked]
>
>07/30/2009 10:02 AM
>To 	Mukul Goyal <[email-masked]>
>
>cc 	ROLL WG <[email-masked]>
>
>Subject 	Re: [Roll] Moving forward with the protocol work
>
>
>
>
>Hi,
>
>Mukul Goyal wrote:
>> Mischa,
>>
>>> We should use this early design stage to come up with one solution - one
>> solution which is not necessarily optimum for all cases but for the
>> (e.g.) 95% quantile. The PHY guys learned to live with such an approach.
>> The MAC folks are getting there and we should take our chance now. 95%
>> means clearly to concentrate on the core issues, of which loop
>> detection/avoidance, p2p and security are somehow still open.
>>
>> When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even
>though it has deficiencies (such as
>P2P routing). But, the implication of giving it the WG status seems to
>be that RPL would be the _framework_ on which all future ROLL work would
>be based. I am not in support of the use of RPL as a framework unless it
>eliminates its current tight coupling with DAGs (a, rather heavy duty,
>loop prevention mechanism).
>
>The goal of the WG from my understanding, is to produce *one* protocol
>in the current charter. RPL is definitely suitable as a starting point
>for that protocol (JP said foundation, not framework). I completely
>support this approach.
>
>From the industry point of view we need a single solution, which
>fulfills application requirements sufficiently and thus can be widely
>deployed commercially.
>
>Regarding loop prevention, so what if RPL does a better job than is
>necessary? Does it break some requirement doing that? If so, we should
>fix it. There are other reasons for using DAGs than just loop prevention.
>
>Zach
>
>--
>http://www.sensinode.com
>http://zachshelby.org - My blog “On the Internet of Things”
>Mobile: +358 40 7796297
>
>Zach Shelby
>Head of Research
>Sensinode Ltd.
>Kidekuja 2
>88610 Vuokatti, FINLAND
>_______________________________________________
>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: "Don Sturek" <[email-masked]>
Date: Fri, 31 Jul 2009 06:22:36 -0700

Hi Mukul,

Could we please see if ROLL can address the P2P requirement to meet your requirements (and Jerry's building controls requirements)?  Alternatively, if you do elect to take up the issue in MANET, I am also interested since as I mentioned Smart Metering has a P2P requirement as well.

In general, I think the P2P issue is unavoidable in ROLL (and assuming we don't lose the DAG for low resource transport of P2MP/MP2P traffic)

Don

-----Original Message-----
From: Mukul Goyal [mailto:[email-masked]] 
Sent: Friday, July 31, 2009 6:07 AM
To: Pascal Thubert (pthubert)
Cc: ROLL WG; [email-masked]; d sturek; Jerald P Martocci
Subject: Re: [Roll] Moving forward with the protocol work

Pascal

Thanks
Mukul
  
----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "d sturek" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "Jerald P Martocci" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, [email-masked]
Sent: Friday, July 31, 2009 7:26:04 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] Moving forward with the protocol work

Hi Don:

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Jul 2009 18:28:19 +0200

Hi Mukul,

On Jul 31, 2009, at 3:07 PM, Mukul Goyal wrote:

> Pascal
>
> OK. This puts all the arguments to rest. Me, Jerry and JP (who has  
> been insisting again and again that ROLL has to provide good P2P  
> solution) had been looking at the wrong WG all along. We should go  
> bang the MANET WG door and ask for a good P2P routing solution for  
> LLNs.

Hold on please. You expressed your opinion, we fully respect it and do  
appreciate the comments. Also needless to say that as a chair I hope  
that you will anyway continue to express your opinion and provide  
input and ideas.
I did say that RPL has to provide a good solution for P2P, simply  
because this is clearly spelled out in the requirements documents.

Please just do not add my name to statements that you made in your  
last two sentences.

Thanks.

JP.

> To: "d sturek" <[email-masked]>, "Mukul Goyal" <[email-masked]>,  
> "Jerald P Martocci" <[email-masked]>
> I'm all with you here. Optimized P2P for all comes at a cost, in  
> particular in terms of states in the nodes, and is clearly a  
> secondary priority for ROLL. OTOH, in a use case where all nodes can  
> really afford all the states involved, the problem seems to drift  
> outside the ROLL charter and back in the MANET world.
>
>> I believe the opposite as to what is proposed below.  I would  
>> propose using the RPL proposal as the baseline
>> 1) The foundation should be as simple as possible - a simple  
>> distance vector approach (I hope there is an
>> draft, constraints and strategies (OCP) and basic rules to decide  
>> when to generate RAs. The foundation should
>> not include any mechanism to deal with loops (so, it should not  
>> include DAGs unless DAGs can be shown to be
>> needs of all the requirement specifications and then ancillary  
>> specifications to meet the specific needs for
>> each of the requirements.  RPL as currently written seems perfectly  
>> suitable for the MP2P requirement, yet not
>> strategy and 3) trickle to cleanly vary periodic requirements.   
>> Then RPL-1 could be then enhancements for MP2P
>> applications and would include the DAG.  This would allow us to  
>> define a different extension, RPL-2, for P2P
>> JP has promised that if I just shut-up and give the DT some time,  
>> they will provide a solid P2P solution.  I
>>> When you say a solution, it seems that you want one particular  
>>> protocol. I am OK with RPL as a protocol even