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

From: Rene Struik <[email-masked]>
Date: Fri, 31 Jul 2009 08:51:42 -0400

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.

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

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 31 Jul 2009 05:59:57 -0700

Hi Rene,

I agree that security may require retention of state information.

The issue in MANET protocols is that many scale retention of state information according to the number of routable destination devices in the network (or alternatively get around it by flooding the network during route discovery).  It is these facilities that don't scale......

Don

-----Original Message-----
From: Rene Struik [mailto:[email-masked]] 
Sent: Friday, July 31, 2009 5:52 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: (On keeping state) Re: [Roll] Moving forward with the protocol work

Dear colleagues:

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,

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

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, 

Jerry 

07/30/2009 10:02 AM 	

Hi, 

Zach 

Zach Shelby 
Head of Research 
Sensinode Ltd. 
Kidekuja 2 
88610 Vuokatti, FINLAND