Subject: Re: [Roll] (On keeping state) Re: Moving forward with the protocol work

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Aug 2009 09:29:51 +0200

Hi Rene,

On Jul 31, 2009, at 2:51 PM, Rene Struik wrote:

> Dear colleagues:
>
> Please be aware that incorporation of security provisions may  
> necessitate retaining some state information on each device, the  
> extent of which depending on security design objectives throughout  
> the life cycle of the system and granularity of security policies,  
> whether for routing security or other reasons. So, even if one were  
> able to remove state with a particular routing design, this does not  
> necessarily imply one can avoid this altogether from an overall  
> system perspective.
>

Absolutely, this is the sort of trade-off that will be discussed  
during routing design.

Thanks.

JP.

> Best regards, Rene
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: 'Mukul Goyal' <[email-masked]>; 'Jerald P Martocci' <[email-masked] 
> >
> Cc: 'ROLL WG' <[email-masked]>; [email-masked] <[email-masked] 
> >
> Sent: Fri Jul 31 08:11:38 2009
> 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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll