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

[C Chauvenet <[e-mail]>]

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 :

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:

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.
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll

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