Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

From: Mukul Goyal <[email-masked]>
Date: Fri, 14 May 2010 00:06:32 -0500 (CDT)

Hi Philip,

[Philip]
I read over p2p-rpl-00. Overall, I think the proposal is sensible. It's clear from the home automation requirements that RPL needs to be able to quickly repair/discover routes. This draft suggests a simple way RPL can support such functionality. The basic mechanism is similar to AODV/DYMO/DSR, which makes sense. The core ideas in all of the protocols are sound, we just need to be careful with the details. I have two major questions:

1) Why are there special measurement packets? This seems to come out of the required functionality section, but I don't understand its original seed. Typically, network and/or route measurement are management concerns and are handled there, rather than inside a routing protocol. This seems like the wrong place to accomplish the goal.

[Mukul]
The intent of p2p-rpl draft is to present the high level description of required P2P functionality. We do not insist that all the functionality be provided within RPL specs. Applications do need a way to measure the "cost" of an existing route. Such cost measurement helps a node decide whether to initiate a P2P route discovery. I guess such a mechanism can also help decide whether additional permanent DAGs are required. I agree with you that RPL specs is perhaps not the right place where the measurement packets and mechanism should be defined. But I think that ROLL WG should define such a mechanism (rather than some other WG) because this mechanism is highly dependent on the metrics and the metric container options defined by ROLL WG.

[Philip]
2) The mechanisms for discovering/establishing "good enough" routes are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism, with the caveat that the goal is "good enough" rather than optimal. But, as is always with such things, the devil is in the details. For example, when a node sends a discovery messages, who can forward it? If we say that *any* node can forward it, we're in dangerous territory; if we say that a node must have the sender in its neighbor set, then things look a lot better (it means there are link estimates and we avoid the AODV hopcount problem). Can you be more specific on what the discovery forwarding algorithm is?

[Mukul]
I guess I am not sure what your concern is. Could you please elaborate. I am not clear why could it be dangerous for a node to forward a discovery message. Ofcourse, the direction of the route being discovered and whether a node knows the local values for the routing metrics being used would determine whether a node forwards a discovery message further or not.

[Philip]
Nits:

4.7 says "To facilitate the use of a DIO as the Discovery message, we suggest the creation of a new "Route Discovery" option that each DIO/Discovery message must carry." I assume this means: 

"We suggest the creation of a new "Route Discovery" option that a DIO message may carry. Inclusion of this option allows a DIO to act as a Route Discovery message."

Otherwise every DIO has to have this option?

[Mukul]
Right. Your text is much better. We certainly did not mean that every DIO must carry the Route Discovery option.

[Philip]
4.7 seems to suggest that any node forwards a Route Discovery; I think this is problematic (see 2 above).

[Mukul]
I guess I need a little more explanation of the problem.

Regards
Mukul

---

From: JP Vasseur <[email-masked]>
Date: Mon, 17 May 2010 15:04:35 +0200

Hi Mukul,

On May 14, 2010, at 7:06 AM, Mukul Goyal wrote:

> Hi Philip,
>
> [Philip]
> I read over p2p-rpl-00. Overall, I think the proposal is sensible.  
> It's clear from the home automation requirements that RPL needs to  
> be able to quickly repair/discover routes. This draft suggests a  
> simple way RPL can support such functionality. The basic mechanism  
> is similar to AODV/DYMO/DSR, which makes sense. The core ideas in  
> all of the protocols are sound, we just need to be careful with the  
> details. I have two major questions:
>
> 1) Why are there special measurement packets? This seems to come out  
> of the required functionality section, but I don't understand its  
> original seed. Typically, network and/or route measurement are  
> management concerns and are handled there, rather than inside a  
> routing protocol. This seems like the wrong place to accomplish the  
> goal.
>
> [Mukul]
> The intent of p2p-rpl draft is to present the high level description  
> of required P2P functionality. We do not insist that all the  
> functionality be provided within RPL specs. Applications do need a  
> way to measure the "cost" of an existing route. Such cost  
> measurement helps a node decide whether to initiate a P2P route  
> discovery. I guess such a mechanism can also help decide whether  
> additional permanent DAGs are required. I agree with you that RPL  
> specs is perhaps not the right place where the measurement packets  
> and mechanism should be defined. But I think that ROLL WG should  
> define such a mechanism (rather than some other WG) because this  
> mechanism is highly dependent on the metrics and the metric  
> container options defined by ROLL WG.

Yes, agree. I would also suggest to make it a separate ID and make use  
of the routing-metric. You do not need that many modifications to what  
exist already.

Thanks.

JP.

>
> [Philip]
> 2) The mechanisms for discovering/establishing "good enough" routes  
> are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO- 
> like mechanism, with the caveat that the goal is "good enough"  
> rather than optimal. But, as is always with such things, the devil  
> is in the details. For example, when a node sends a discovery  
> messages, who can forward it? If we say that *any* node can forward  
> it, we're in dangerous territory; if we say that a node must have  
> the sender in its neighbor set, then things look a lot better (it  
> means there are link estimates and we avoid the AODV hopcount  
> problem). Can you be more specific on what the discovery forwarding  
> algorithm is?
>
> [Mukul]
> I guess I am not sure what your concern is. Could you please  
> elaborate. I am not clear why could it be dangerous for a node to  
> forward a discovery message. Ofcourse, the direction of the route  
> being discovered and whether a node knows the local values for the  
> routing metrics being used would determine whether a node forwards a  
> discovery message further or not.
>
> [Philip]
> Nits:
>
> 4.7 says "To facilitate the use of a DIO as the Discovery message,  
> we suggest the creation of a new "Route Discovery" option that each  
> DIO/Discovery message must carry." I assume this means:
>
> "We suggest the creation of a new "Route Discovery" option that a  
> DIO message may carry. Inclusion of this option allows a DIO to act  
> as a Route Discovery message."
>
> Right. Your text is much better. We certainly did not mean that  
> every DIO must carry the Route Discovery option.
>
> [Philip]
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll