[Roll] question about DAO-ACK

[Michael Richardson <[e-mail]>]

<REMOVES CHAIR HAT>

Given:
        - a storing implementation
        - DAO-ACKs requested
        - three nodes: A <- B <- C. A is the root.

C sends a DAO with the K bit set to selected parent B.
B will need to send a DAO to A indicating that it knows about C.

Question
1) should B wait until it receives a DAOACK from A before
   sending a DAOACK back to C?
   (before you answer, consider the the tree could be very
   deep, and that this implies that the intermediate nodes
   have to keep potentially many outgoing DAOACKs in a queue)

   Or is it enough that B says, "okay, I got you", and then
   takes responsibility for sending reachability information
   on its own?

   The problem I have with not waiting is that if C thinks
   it is on the network when it gets the DAOACK, it can start
   sending traffic upwards, but downward packets would get lost for awhile.
   Further, it is going to start sending DIOs, and start attracting
   traffic from other nodes when really, it isn't ready to do so.

2) if B recieves a DAO with the K bit set from, does this imply
   that it ought to set the K bit to its parent?
   If the answer is no, and you answer the question (1) that B ought to
   wait until it has heard from A before answering, but B
   has a policy of not setting the K bit, should B then
   answer immediately?

3) in the non-storing case, if a parent (B) of C, in fact had
   multiple interfaces, node C might not see the interface
   that is closer to A, and can only, in the Transit option,
   indicate the interface that it does see.  This implies
   that root A, may have to do two lookups to figure out
   where Bdown is, as it likely only has route to Bup.

4) what is the use case for the RPL Target Descriptor?

======

The DAO-ACK mechanism is pretty important to assure bi-directional
reachability, and the security-threads document makes reference to it.

I had not clued in that the K bit was optional before.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-