[Roll] On draft-ietf-roll-aodv-rpl-01

[Juan-Antonio Cordero-Fuertes <[e-mail]>]

Concerning draft-ietf-roll-aodv-rpl-01, I have some comments / questions:

1) Route discovery in AODV-RPL from OrigNode to TargNode is performed by forming temporary paired DODAGs at OrigNode and TargNode (secs. 3 and 4); these DODAGs are formed by multicasting RREQ-Instance and RREP-Instance messages over the sensor network, respectively. 

It is known that multicasting in wireless multi-hop ad hoc networks, and in particular LLNs as those expected to use (Asymmetric) AODV-P2P-RPL, is likely to lead to collisions and packet losses, more frequent as the network is more dense, and jittering mechanisms (Inf. RFC 5148 [2]) have been proposed in the IETF and implemented in MANET protocols using multicasting or broadcasting, to reduce the probability of such collisions.

Route discovery in reactive routing protocols over LLNs is one of the cases in which multicast RREQ collisions may severely degrade protocol performance, and jittering may be helpful to reduce the number of collisions.

The use of random jittering mechanisms as proposed in RFC5148 [2] in reactive route discovery may distort the routing metrics and lead to the discovery and installation of suboptimal routes, as a result of the "delay inversion" effect (sec. 3.1 [1]). However, this effect can be alleviated with simple, easy-to-implement modifications of the original jitter mechanism, also specified and evaluated in [1] (secs. 3.2, 3.3, 4 and 5).

Since packet collisions are inherent to route discoveries based on multicast in LLNs, it may be helpful to address the problem in the draft specification itself, and provide pointers to (or directly describe) mechanisms to alleviate their impact by using optimized jittering techniques.

2) I observe that Experimental RFC6997 [4] is mentioned as a normative reference for this draft, for which the intended status is Standards Track, although this practice is discouraged, if I understand correctly (RFC2026 [2]). Is there any reason to keep RFC6997 as a normative reference in this case? I mention this because my previous comment would need to be applied as well to RFC6997, as "parent" of the draft, if used as a normative reference to the intented-Standard draft-ietf-roll-aodv-rpl-01 -- but would not be necessary for an Experimental RFC. 

Thanks a lot,

Juan Antonio Cordero, PhD
École polytechnique, Paris

References

[1] Juan Antonio Cordero, J. Yi, T. Clausen: An Adaptive Jitter Mechanism for Reactive Route Discovery in Sensor Networks. Sensors (Basel). 2014 Aug; 14(8): 14440–14471. doi:10.3390/s140814440
[2] RFC 5148, Informational
[3] RFC 2026, BCP
[4] RFC 6997, Experimental