[Roll] Review of draft-ietf-roll-rnfd-02

["S.V.R.Anand" <[e-mail]>]

Dear Konrad,

Thank you for your nicely written draft that draws attention to the severity of
the LBR failure and proposes a solution for faster early detection of such a
failure. In this review, I will try to summarize my thoughts on the
same which will hopefully help in enhancing the document.

1) After the reading document, I am tempted to ask this question as to how
come such a serious problem which can disrupt the service for several minutes
got unnoticed till today after so many years of large scale RPL deployments
across the world and lot of RPL related research work that had gone in. Surely some of
those real-world deployments might have implemented their own proprietary
methods to minimize the service disruption without any changes to RPL protocol.
Having multiple LBRs for the purpose of combating LBR failures and load
balancing is not new. 

Since LBR is straddling between wired and wireless worlds, proper functioning
of the IoT network is essential for wireless sensor data producer and the wired
sensor data consumer/actuator. This means both these end points can potentially
detect LBR failures. While the RNFD document tackles the problem from the LLN
side, one can use plethora of schema for quickly detecting LBR failure from the
wired side deterministically at negligible cost. In the presence of multiple LBRs
and the use of virtual roots one can reroute the packets to the other LBRs.

I came across an interesting work that has been carried out in Inria research
"RPL cooperation experiments using FIT IoT-LAB testbed". In particular, the
paper titled "Sharing is caring: a cooperation scheme for RPL network resilience
and efficiency". Here coordination happens between LBRs over wired network to
detect LBR failures.  The other LBRs pass on the LBR failure information into
the LLN. (Source: https://inria.hal.science/hal-02095410/file/papier.pdf).

Giving a brief summary of strategies adopted by IoT deployments that bring
resilience to LBR failures may not be out of place. Also, RNFD protocol can
take benefit from other schemes that are available.

2) Assuming the time gap between border router failures due to power outages is
long, it is not apparent from the document the energy consumption and its
impact on the node/network lifetime due to the consensus process which is
always running in the background. I know, it depends :) But it is good to
include experimental results that indicate RNFD performance under different 
network scenarios. 

3) Refer to section 5.2.  Detecting and Verifying Problems with the DODAG Root

- Apart from NUD and Layer 2 triggers, I think "overhearing" technique as a means
  to infer the neighbors' state can help reducing the message exchanges and
  faster LBR failure detection. What are your thoughts on this ? 

- How does the RNFD work in the presence of RDC ? How is the causality 
  of information is maintained in such a situation ?

- What happens if certain conditions result in a state that keeps toggling ?  I
  think RNFD needs to have additional algorithms in place on top of link
  failure detection schemes such as NUD.

4) For minimizing false positives, and false negatives, we would expect the
   Sentinel nodes to be running some internal algorithm that decide on the state
   changes between “SUSPECTED DOWN” and “LOCALLY DOWN”. I suppose this algorithm
   is important for the proper functioning of RNFD protocol. In order to maintain
   consistency and robustness among different implementations, a reference
   algorithm will be useful to be given in a separate section or appendix.

5) Refer to 5.3.  Disseminating Observations and Reaching Agreement

- How does one set RNFD_CONSENSUS_THRESHOLD value ? Is it constant across the
  network or it depends on factors like network topology, traffic pattern and so on ? 
  Also, does this number remain fixed for the entire lifetime of the network or needs
  to be adapted over time ?

- A curious question. I would assume that even if just one node indicates that
  LBR is UP at any time through PositiveCFRC, then LBR can be considered up at
  that time. Isn't it ?  This precise time epoch is what should be considered in
  deciding the liveliness of the LBR. In the absence of the notion of time, the
  question of "latest" information does not arise. Is there a risk of a wrong 
  conclusion, especially if the number of good links are less ?

There is a small typo in 3.2. Counters and Communication. "acros" to be changed to "across"

----------------------------------------------------------------------------------------

Thank you for your time. I hope you found the points that I brought out are 
reasonably good and help in improving the draft.

Regards
Anand