[Roll] Review of draft-ietf-roll-aodv-rpl-12

[Konrad Iwanicki <[e-mail]>]

Dear authors,

I have the following remarks regarding the draft. (The comments are 
based solely on the contents of the draft. I did not review the change 
log nor any meeting proceedings.)

# Major issues / questions:

1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer 
necessary, a timeout solution is used: the L field in the RRE(Q|P) 
messages. Although this is not formulated explicitly in the draft, from 
the format of the messages, I assume that the timeout is counted locally 
and independently by each node, from the moment it joins the 
corresponding DODAG. In particular, depending among others on the 
network topology, the configuration of Trickle, and the underlying 
link-layer, a node may start a timeout for a DODAG after another has 
already left this DODAG. This is dangerous as it may lead to situations 
in which information about a DODAG is never garbage-collected because 
nodes that leave the DODAG may rejoin it upon hearing information from 
other nodes that are still in the DODAG. I would opt for an alternative 
solution or at least some poisoning- or grace-period based approach. In 
addition, it would be nice to have in the draft a potential risk 
analysis regarding the configuration parameters of the solution.

2. What is the rationale behind deleting by TargNode the DIO ART Option 
containing its address (and then taking address set intersections when 
propagating the DIOs)? What problem do these mechanisms aim to solve? A 
node can still receive DIOs along multiple paths. It should be able to 
choose the "most desirable one". Deleting the target address and using 
the intersection mechanism described in Sect. 6.2.2. may actually 
preclude this behavior if the "most desirable path" for a TargNode is 
not the one it obtains first. For example, consider the following 
circular network:

   A1 - OR - B1
   |         |
   A2        B2
   |         |
   T1 - T2 - B3

with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting as 
intermediate routers. Suppose that the path over nodes B* is the most 
desirable one for both T1 and T2. Now, consider the following scenario. 
T1 receives an RREQ-DIO first from A2 and joins the RREQ-DODAG. It then 
propagates the DIO to T2 but with ART Option with its own address (T1) 
removed. In effect T2 also joins the RREQ-DODAG, remembering however 
that the last RREQ-DIO contained only T2. Now, T2 finally receives an 
RREQ-DIO from B3. It does not propagate to T1 this path because: (1) it 
removes its own address from the DIO and (2) the address of T1 is not 
included because of taking the intersection of the address sets T2 
received in the DIOs along the two paths. In effect, T1 will never learn 
the most desirable path. Is this what is expected to happen or am I 
missing something? Again, it is not clear to me what the goal of the 
removal and intersection is. In the end, original RPL creates routes 
from multiple targets (all nodes) to the root, so why does this protocol 
require dynamically removing the targets?

3. A related concern applies to Sect. 6.2.6., more specifically, to the 
second statement: "If, on the other hand, TargNode was already 
associated with the RREQ-Instance, it takes no further action and does 
not send an RREP-DIO." To me, it implies that TargNode replies with 
RREP-DIO to the first RREQ that results in its joining the corresponding 
RREQ-DODAG. In particular, if it learns about a better path to OrigNode, 
it does not use this path instead of the first path it joined. Again, am 
I missing something or is this intentional? If so, it seems somewhat 
conflicting with the second paragraph of Sect. 6.3, which allows the 
node to wait for RREP_WAIT_TIME before replying. Trying to combine these 
two sections, my understanding would be that TargNode sends an RREP to 
the best path that it is able to learn within the RREP_WAIT_TIME. If 
this was the intention, then what is the rationale behind setting the 
default RREP_WAIT_TIME to 0 for L = 0? This would imply that for an 
RREQ-DODAG that is to be maintained infinitely long, only the first path 
to OrigNode learned by TargNode is considered. In general, why not 
introduce into the protocol algorithms for TargNode to update its path 
when it learns a better one? This would also require updating RREP 
propagation, which is again done only for the first received message 
(per Sect. 6.4).

4. It is not entirely clear to me how Trickle timers govern 
transmissions of multicast RREQ/RREP DIOs. In particular, when the 
timers are reset? How is this policy influenced by the fact that, in 
line with my previous comments, in principle a node reacts only the 
first RREQ/RREP DIOs that cause its joining the corresponding DODAGs. 
Perhaps a bit extended discussion of these issues could be provided in 
Sect. 8.

5. There is also no discussion in the draft of a situation in which a 
node has no resources to join a RREQ- or RREP-DODAG. While in the case 
of RPL, this is arguably not that relevant, in the proposed protocol, 
there may be many concurrent DODAGs, and hence it is intuitively more 
likely that some nodes may lack resources to handle all DODAGs.


# Smaller issues / nits:

Page 4, definition of "AODV": add a space between "Routing" and "[RFC3561]".

Page 4, definition of "DODAG RREQ-Instance": "control message 
transmission" (hard to parse) => "transmission of control messages"

Page 4, definition of "DODAG RREP-Instance": the same as above

Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode to 
TargNode" is confusing as DIO messages are link-local. Changing this to 
""RREQ-DIO message" means a DIO message from OrigNode toward TargNode" 
may sound better. The same applies to the next statement.

Page 8, definition of "L": "the time" => "time"

Page 8, definition of "MaxRank" is confusing. The name would suggest 
that this is the maximal allowed value, whereas the text implies that 
this is the minimal disallowed value. Perhaps the name "MaxRank" could 
be changed to something else, like "RankLimit".

Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would 
be" => "Any other node MUST NOT join..."

Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be 
shorter than the lifetime of the RREQ-Instance to which it is paired. 
What if the lifetime of the RREQ-Instance is infinite? In general, why 
such a requirement?

Page 14, the last paragraph, text starting from "It does this..." is 
unclear to me. What happens in the end with MaxUseRank? (This is the 
first and only paragraph where this symbol occurs.)

Page 18, the last paragraph: term "shift" is somewhat misleading (to me 
it describes bit shifts: right shift, left shift). Perhaps "offset" or 
"delta" would be better.

Page 18, the last paragraph: The text starting with "In RREP-DIO option, 
the Shift field..." seems confusing. More specifically, it is not clear 
to me what is shifted/offset: (1) does the receiving node have to offset 
the RPLInstanceID in the RREP-DIO to obtain the RPLInstanceId in the 
RREQ-DIO OR (2) is the RPLInstanceID in the RREP-DIO equal to the 
RPLInstanceID in the RREQ-DIO but the receiving node should offset the 
former so as to avoid conflicts? I guess it is (1) but am not sure based 
on the text. In particular, what "original" means there?

Page 18, the last paragraph: "would prevent intermediate routers to 
distinguish" => "would prevent intermediate routers from distinguishing".

Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" => 
"Otherwise, in case of an asymmetric route"

Page 20, Sect. 7, the second paragraph: "is at least as large" as what? 
As the sequence number in the RREQ-DIO message?

Rather than / in addition to Appendix A, perhaps citing relevant 
scientific papers may be informative?


That seems all given the time I had. Hope that the review helps.

Best,
-- 
- Konrad Iwanicki.