Subject: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04 and draft-ietf-roll-p2p-rpl-09

From: JP Vasseur <[email-masked]>
Date: Wed, 7 Mar 2012 14:15:12 +0100

Dear all,

The two documents draft-ietf-roll-p2p-measurement and draft-ietf-roll-p2p-rpl have been discussed on the mailing list and during 
WG meetings for some time, there several implementations that are now stable, and the authors believe that the documents are
ready for WG Last Call.

Thus, this starts a Working Group Last Call on:
* draft-ietf-roll-p2p-measurement-04
and
* draft-ietf-roll-p2p-rpl-09

Furthermore, an interoperability was carried out last month with INRIA's implementation against Sigma Design's implementation.
The report can be found: http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

Experiments with P2P-RPL have also taken place on the Senslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz: 
http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf

The WG Last Call will last 3-weeks and will end on March 29, at noon ET. Please send your comments on the mailing list and copy 
the authors.

Thanks.

JP and Michael.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Mar 2012 08:14:27 +0100

This is just a reminder that we have 2 documents in WG Last Call, which will terminate on March 29, at noon.
Comments appreciated.
Thanks.

JP.

On Mar 7, 2012, at 2:15 PM, JP Vasseur wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Mar 2012 12:50:51 -0700

Comments on p2p-measurement:

Overall this draft is very solid. It sets out a very simple mechanism and its options. The use cases are especially helpful.

The one major thing that seems to be missing in the document, however, is exactly how one populates and updates the metric container. For example, what metrics should a node put into the metric container? The metrics that the DODAG root is advertising for that RPL Instance? What happens if the network is using MRHOF and so ETX directly through Rank? The only text I can find is the last paragraph of 5.0:

"   Next, the router MUST update the routing metric objects, contained in
   the Metric Container options inside the MO, either by updating the
   aggregated value for the routing metric or by attaching the local
   values for the metric inside the object.  After updating the routing
   metrics, the router MUST unicast the MO to the next hop."

Is it that the metric container behavior is specified elsewhere? If not, then it's possible for a node meeting this document specification to do whatever it wants with the metric container. I can see a few options:

1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward or reverse route, something the document should be clearer on. This has the advantage that it requires less coordination and specification with respect to RPL and OFs. It has the disadvantage that a node could request a metric the network does not support.

2) All nodes follow the metrics in DIOs. This has the advantage that the ability to handle these metrics is well defined by a RPL instance. It has the disadvantage that it requires coordinating how OFs manage metrics with path discovery.

Phil

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Mar 2012 12:57:23 -0700

Comments on draft-ietf-roll-p2p-rpl-09:

I did not review the entire document; I read through the basic mechanisms and focused on 9.2 (Trickle operation for P2P Mode DIOs). I think that this section is well written and clearly states how p2p should interact with Trickle. Furthermore, those interactions seem sound. I'll read through some of the experimental reports and send more complete comments later.

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 16 Mar 2012 16:53:41 -0500 (CDT)

Hi Phil

Thanks for pointing out the problem.

>1) The originator specifies the metrics of interest and nodes update this value as they generate responses/replies. Part of the challenge here is a question of whether one is measuring the forward o…

This is what we have in mind. I will make it clear in the next revision of the draft. Also, I will clarify that the route being measured is the one in forward direction (from the origin to the target) and an intermediate router MUST drop a Measurement Request if it cannot update (or add local value to) a routing metric specified inside the Metric Container.

Thanks
Mukul 

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "ROLL WG" <[email-masked]>
Sent: Friday, March 16, 2012 2:50:51 PM
Subject: Re: [Roll] ROLL WG Last Call on draft-ietf-roll-p2p-measurement-04

Phil

---

From: C Chauvenet <[email-masked]>
Date: Thu, 29 Mar 2012 00:18:12 +0000

Hi,

Here is my review of the P2P draft :

Overall, I think this mechanism is very relevant for certain RPL applications such as home or building automation, or when you think that the effort to find a more optimal route is worth compare to the DAG that the RPL core specification can form. Also, it provides an "on demand" route discovery that can significantly melt down the control overhead of a route that is used for a limited period of time, rather that being continuoulsy maintained.

On big question that rise my mind is, what happened if the route discovery fail ?
Some protocols sends out an error message when the route discovery fails or get stuck.
Do authors think that it could be relevant to add a "discovery-error" message as defined in other route discovery protocols ?

Another point that has been discussed today during the ROLL meeting, is that some people may find other mechanisms than trickle more efficient to flood the RDO.
Could we let the door opened to other flooding optimization mechanism, or explicitly say that the trickle mechanism MUST be used ?

In details :

p3 : P2P-RPL does not guarantee discovery of a route.

But how do we know if the RDO has been lost, of if the request has failed ?
in other words, how do we know if the route doesn't exist, or if the request has been lost ?
In addition, it may be relevant to cite an example where the discovery of a route cannot be achieved.

p5 : If there is

   no existing route between the origin and the target(s) or the cost
   measurement for the existing routes fails, the origin will have to
   guess the constraints to be used in the initial route discovery.

Any recommendation to guess the metric in use ? Is it relevant to use hop count by default (to limit the scope) ?

p6 : P2P-RPL

   allows for the discovery of one hop-by-hop route or upto four source
   routes per target.

upto --> up to.
Why 4 ? Any reason to limit the choice to 4 ?

p6 : P2P-RPL does not guarantee discovery of a route to a

   target.

Same text, same remark as before !

p6 : A P2P mode DIO always carries one P2P Route Discovery

   Option (defined in Section 7.1<http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-09#section-7.1>) in which the origin specifies the
   following information:

So you should put a MUST for this.

p9 : o DIOIntervalMin: 6, which translates to 64ms as the value for Imin

      parameter in Trickle operation.

Should we really fix numbers in this spec ? Could we turn the MUST of these parameters into recommended values ?
Not sure this timing is applicable to all RPL networks.

p12 : This specification does not allow for

      the establishment of hop-by-hop routes in the backward direction.

Why ? This would enable to establish 2 routes within a single route request.
Furthermore, you stipulates in the draft that links have to be bidirectional to propagates RDO, in order to be able to send back the DRO.
So if I understand it correctly you ensure that you have a reliable path in both ways. Why using it in a single way only ?

p13 : The IPv6 addresses in the Address vector MUST be reachable in

         both forward and backward directions.

Does it means that links have to be bidirectional on the path ? How do you verify that ?

p14 :  A DRO message travels

   from the target to the origin via link-local multicast along the
   route specified inside the Address vector in the P2P-RDO.

Why using multicast if you know every destinators ?
Could we unicast packets to each destinators in the address vector ?

p15 :  Stop (S): This flag, when set to one by a target, indicates that

      the P2P-RPL route discovery is over.

Is this bit really usefull ? My guess is that it will be always set to 1.
If you hear a DRO, this indeed means that the RDO has reached the target, so you could just stop processing RDO when you hear a DRO.
Do we really need a flag to stop RDO processing or the hearing of a DRO type message could do the job ?

p21 : Example methods include

   selecting each route that meets the specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.

How could we know the time to wait until we get all the RDO ?
Is there a way to evaluate it according to some parameters related to the network (diameter of the network for instance) ?

p25 : o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO-

      ACK before retransmitting a DRO message.  DRO_ACK_WAIT_TIME has a
      value of 1 second.

I'm not sure it is compliant with all RPL deployments.
Could we adapt it to the characteristics of the network used ?

p28 : References need to be updated according to recent RFCs.

Best,

Cédric.

Le 16 mars 2012 à 08:14, JP Vasseur a écrit :

JP.

Dear all,

Thanks.

JP and Michael.
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 Mar 2012 19:15:42 +0200

Dear all,

WG Last calls have now ended. Thanks to all of you who commented - as a reminder this document will follow the EXPERIMENTAL track (as a reminder since this was asked during the ROLL WG meeting).

Authors, could you please address the number of comments posted on the mailing list ?

Thanks.

JP and Michael.