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

From: Mukul Goyal <[email-masked]>
Date: Tue, 4 Aug 2009 20:24:21 -0500 (CDT)

Hi Kris,

Sorry for the delay in getting back. 

Since the DAG mechanism seems a fait accompli now, my objections to DAGs are irrelevant.

In light of the recent email exchange I had with Jonathan, I view DAGs as a mechanism that:

1) provides default routing paths to RFDs;
2) allows hard bounds on routing state a node has to maintain irrespective of the number of destinations in the network and the number of nodes in the neighborhood; 
3) constrains the LLN topology so that the spread of routing costs can avoid broadcast;
4) provides loop prevention;
5) provides good MP2P and OK P2MP routing.

In the LLN scenarios, where there is no FFD backbone available, RPL seems like a good choice.

I am hoping that future P2P optimizations in RPL would allow:
1) more stateful routing to take place along the FFD backbone (if such a backbone exists in the LLN), where the topology need not be constrained along DAGs;
2) provide options regarding how to deals with loops. There are 4 choices for these options: prevention, avoidance, detection+correction and not dealing with loops at all;
3) allow some sort of source-initiated route discovery. Right now, a non-DAG-root destination can be reached only if it advertizes itself via a DAO.

Thanks
Mukul

----- Original Message -----
From: "Kris Pister" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "d sturek" <[email-masked]>, "ROLL WG" <[email-masked]>, [email-masked]
Sent: Friday, July 31, 2009 10:00:10 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Moving forward with the protocol work

Mukul - I'm trying to understand your concern with DAGs.  Is it the "A" 
that bothers you?
A requirement from industrial is that the protocol allow graphs not just 
trees (it's difficult for me to refrain from using words like insist and 
abhor here), so the G is important.  Directed is equivalent to 
"routing".  Acyclic by some mechanism seems like a good idea, but not 
something that the design team was fanatic about.  What am I missing?

ksjp

Mukul Goyal wrote:
> Don
>
> I will get back to the list regarding the scalability and flooding (BTW, the solution I proposed does not involve flooding, which I abhore with same vengeance as you) argument you made in favor of RPL and again the alternate solutions. Also, I will wait for DT solution for good P2P routing in RPL, but it seems to me that it has to involve some state maintenance in nodes.
>
> But, for a moment, lets forget about the alternate solutions. Lets just focus on RPL.
>
> All I am saying is that RPL, at present, is too tightly coupled with DAGs, which is a loop prevention mechanism as I understand it. Putting a specific loop prevention mechanism, a non-essential requirement, in the _foundation_ does not sound like a good idea to me.
>
> Thanks
> Mukul
>  
> ----- Original Message -----
> From: "Don Sturek" <[email-masked]>
> To: "Mukul Goyal" <[email-masked]>, "Jerald P Martocci" <[email-masked]>
> Cc: "ROLL WG" <[email-masked]>, [email-masked]
> Sent: Friday, July 31, 2009 7:11:38 AM GMT -06:00 US/Canada Central
> 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 
>
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 5 Aug 2009 07:35:22 +0200

Hi Mukul,

Just one quick comment. I would just rather say that it is primarily  
optimized for P2MP and MP2P (the good and OK are debatable) while  
supporting P2P - we now need to discuss whether this is good enough. I  
would certainly argue on the distinction between constrained and non  
constrained devices (by the way please avoid the terms RFD, FFD and  
Backbone here).

See below

On Aug 5, 2009, at 3:24 AM, Mukul Goyal wrote:

> 2) allows hard bounds on routing state a node has to maintain  
> irrespective of the number of destinations in the network and the  
> number of nodes in the neighborhood;
> 1) more stateful routing to take place along the FFD backbone (if  
> such a backbone exists in the LLN), where the topology need not be  
> constrained along DAGs;
> 2) provide options regarding how to deals with loops. There are 4  
> choices for these options: prevention, avoidance, detection 
> +correction and not dealing with loops at all;

We need to be careful here not to come up with a protocol having a  
number of options, this is the best way to break interoperability.

> 3) allow some sort of source-initiated route discovery. Right now, a  
> non-DAG-root destination can be reached only if it advertizes itself  
> via a DAO.
>

Requires discussion .... Could you elaborate on your requirements ?

Thanks.

JP.

>> I will get back to the list regarding the scalability and flooding  
>> (BTW, the solution I proposed does not involve flooding, which I  
>> abhore with same vengeance as you) argument you made in favor of  
>> RPL and again the alternate solutions. Also, I will wait for DT  
>> solution for good P2P routing in RPL, but it seems to me that it  
>> has to involve some state maintenance in nodes.
>>
>> All I am saying is that RPL, at present, is too tightly coupled  
>> with DAGs, which is a loop prevention mechanism as I understand it.  
>> Putting a specific loop prevention mechanism, a non-essential  
>> requirement, in the _foundation_ does not sound like a good idea to  
>> me.
>>
>> Thanks
>> Mukul
>>
>> To: "Mukul Goyal" <[email-masked]>, "Jerald P Martocci" <[email-masked] 
>> >
>> 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
>>
>>
>> 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
>>
>> 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
>>
>>
>>
>>
>>> 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
>>>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll