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

[Konrad Iwanicki <[e-mail]>]

Dear Anand,

Thank you for the insightful review. I will try to get back sometime soon.

Best regards,
-- 
- Konrad Iwanicki.

On 16/11/2023 10:52, S.V.R.Anand wrote:
> 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
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll