Re: [Roll] reminder - end of second WG LC

[Mukul Goyal <[e-mail]>]

Hi Joseph

Thanks for your comments. Please see my response inline.

[Joseph]
Section 5:
"...By not allowing the generation of DRO messages, an Origin can use P2P-RPL as purely a mechanism to deliver time-critical application data..."
I question the value of this. The use of trickle timer necessarily adds a minimum delay on each hop. So, it would be faster to use the normal DODAG in most cases even if that route takes more hops. And the normal route would impose much less burden on the intermediate nodes. 

[Mukul]
This feature is perceived useful in scenarios (e.g. in home automation) where there is no global DODAG to provide a default path between the source and the destination or such default path is known to be broken. We could have insisted that P2P-RPL is strictly a route discovery protocol and hence DROs must always be generated. But then we thought the facility to do trickle-controlled data delivery could be really useful in scenarios where the only other option is uncontrolled flooding. And it was so easy to provide this facility (simply use P2P-RPL with data option and with DROs turned off). As I mentioned, this facility was perceived as useful in home automation scenarios. Regarding whether such data delivery could be fast enough, I think one could always adjust the trickle parameters to meet the latency requirements.

[Joseph]
Section 6.1:
"...A P2P-DIO MAY carry one or more RIO and PIO options..."
I am not sure how these options should be used by the DAG members. Later on, in 9.1, it says that "..the temporary DAG must not be used to route packets....". So what is the purpose of RIO and also PIO ?

[Mukul]
The RIO would advertize to the target(s) the origin's connectivity to the specified prefix. Regarding PIO, I would very much like to allow P2P mode DIOs to carry PIOs to propagate prefixes for address selfconfiguration (i.e. have A flag set). I think we could forbid setting the R flag to one in a PIO carried in a P2P mode DIOs. Regarding the L flag, I think we could allow a P2P mode DIO to carry a PIO with L flag set subject to the following rules in RFC 6550:

A RPL node
         acting as a router MUST NOT propagate a PIO with the 'L' flag
         set.  A RPL node acting as a router MAY propagate a PIO with
         the 'L' flag not set.

What do you think?

[Joseph]

Default DoDAG config option values:
DIOIntervalMin of 6 is too small for most networks. For default parameter, suggest using 7.

[Mukul]
Changing 6 to 7 would double up the minimum latency for route discovery. DIOIntervalMin 6 corresponds to trickle Imin 64ms, which sounds reasonable/useful. As far as I can remember, this value worked just fine in the testing that Sigma Design and INRIA did with their P2P-RPL implementations. Could you share more details regarding why 7 would be better? I will also check with my co-authors in this regard.

[Joseph]
Also, default Lifetime values of infinity does not seem like a good idea for a "temporary DAG"
[Mukul]
Lifetime in the configuration option is for routing state and not for the "temporary DAG". Temporary DAG's lifetime is specified in P2P-RDO.

[Joseph]
Section 9.2:
Suggest that Imax setting should be less that the DAG lifetime value
[Mukul]
I think Imax value is not critical because of the reasons given in Section 9.2:

The Imax parameter SHOULD be set to a large value (several orders
      of magnitude higher than the Imin value) and is unlikely to be
      critical for P2P-RPL operation.  This is because the first receipt
      of a P2P mode DIO for a particular temporary DAG is considered an
      inconsistent event and would lead to resetting of Trickle timer
      duration to the Imin value.  Given the temporary nature of the
      DAGs used in P2P-RPL, Trickle timer may not get a chance to
      increase much.

Default value 20 (from RFC6550) of DIOIntervalDoublings would make Imax much larger than maximum temporary DAG lifetime, which looks fine to me. Could you explain why Imax should be less than DAG lifetime?

[Joseph] 
Section 9.4
Bullet 1: 
Under what conditions would a router receive the same DIO and a Data-Option with higher sequence number? I assume that only the Originator can include a Data-Option ? Same question also arises for section 9.5 ( para 1 )

[Mukul]
Yes, only the origin can include a data option for delivery to the target(s). In theory, the origin might have newer data to convey to the target(s) while the route discovery is still going on. Sequence numbers accounts for that possibility. Note that Data option did not have a sequence number earlier (before the first LC). Then, Pascal raised the possibility what if origin changes the data option. How would intermediate routers and target know that this is the newer data? Hence, we introduced the sequence number.

[Joseph]
Section 9.5:
"...The Target must transmit the DRO message via the link-local multicast.."
Not sure why it would use link-local multicast...shouldn't it just transmit along the reverse route collected in the P2P-RDO ?

[Mukul]
DRO needs to be transmitted by link-local multicast to allow the spread of Stop flag (which says: dont send or process any more DIOs) to as many nodes as possible. Still, only the nodes on the discovered route are allowed to forward it any further.

[Joseph]  
Section 9.6:
"...This hop-by-hop lifetime must expire at the end of the lifetime specified by the default ..."
The lifetime specified in the DODAG config option is intended to limit the DAG lifetime which is used only for discovering the route. However, the actual route lifetime would be used for a much longer period of time. If it expires so quickly, then it would seem that practical use of the p2p-rpl is limited to the source routing option.

[Mukul]
The correct text you are quoting is 

"This hop-by-hop routing state MUST expire at the end of the
         lifetime specified by the Default Lifetime and Lifetime Unit
         parameters inside the DODAG Configuration Option used in P2P
         mode DIOs for this route discovery.
"

As the text above says, the lifetime in configuration option is for routing state. The DAG's lifetime is specified in P2P Route Discovery Option (P2P-RDO). The DAG's lifetime would be a few seconds. The (hop-by-hop) routing state could potentially live forever. Does this clarify things?

[Joseph]
Section 11:
It would seem that only the Originator of the temporary DAG can use the routes created by it. The intermediate nodes are storing the routes but cannot actually use them. Is my  understanding right ?

[Mukul]
Yes. If using the RPL option (RFC 6553), only the origin can use the discovered route. The intermediate nodes can only use the routing state they store to forward the packets that bear the correct DODAGID (specified as the source IPv6 address of the packet) and the correct RPLInstanceID.

[Joseph]   
Section 12:
..In general, P2P-RPL operation does not affect core RPL operation.."
I think this is unfortunate as P2P can be used to fix issues with core rpl. For example, in core RPL, there is no way to repair a downward route until the actual Target sends another DAO, which can take a long time. It would be very nice if the DoDag root can use P2P-RPL to discover a route to a Target node that is unreachable and then use the resulting source route as the downward route.  

[Mukul]
What the text you quoted means is that it does not break core RPL operation. P2P-RPL can certainly be used in the manner you specified. The root of a global DODAG can certainly use P2P-RPL to discover a source route to any target. Just that it will involve creation of a separate temporary DAG. If you want to do this route discovery within the scope of the existing global permanent DAG, it can be done but needs to be written up in a separate document. I dont think this provision should be inside P2P-RPL document. This is because, for RPL deployments that would not otherwise support P2P-RPL, it may be more efficient to simply use an RPL Target Option inside a DIO to trigger DAOs that would allow desired route to be discovered. Ofcourse, this needs to be written up to (since currently Target Option cannot sit inside a non-P2P mode DIO).

Thanks
Mukul






From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of JP Vasseur
Sent: mercredi 23 mai 2012 23:44
To: roll WG
Cc: Michael Richardson
Subject: [Roll] reminder - end of second WG LC

Second last call on

* draft-ietf-roll-p2p-measurement-05 and
* draft-ietf-roll-p2p-rpl-12

will end May 25th at noon ET, just a reminder.

Thanks.

JP.

On May 11, 2012, at 2:20 PM, JP Vasseur wrote:


Dear all,

A first WG Last Call took place on March 16th on:
* draft-ietf-roll-p2p-measurement-04 and
* draft-ietf-roll-p2p-rpl-09

Thanks to all of you for the fruitful and constructive comments received during WG Last call, that led to several tickets that have been successfully closed, leading to new revisions of these documents.

This starts a new 2-week WG last call on:
* draft-ietf-roll-p2p-measurement-05 and
* draft-ietf-roll-p2p-rpl-12

The WG Last call will end on May 25th at noon ET. Please send your comments on the mailing list and copy the authors.

Thanks.

JP and Michael.


Begin forwarded message:

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