Re: [Roll] Border router failure detection

[Rahul Jadhav <[e-mail]>]

Welcome Konrad and great to hear you on ROLL,

I had access to your paper (through my office IEEE act) and have read the
problem statement and the proposed solution.

I have a few questions with regard to the problem statement before we dive
into the solution part.

Border Router (BR) crash/restart is an issue and any deployment needs to
tackle it (IMO, in version 0.1). As I understand the aim of the paper is to
ensure that the attached nodes should detect the BR failure asap. Just
curious to understand how the nodes use this information in your
deployments? What will be the use-case of this detection?

In my deployments, my focus was to get the BR restarted as soon as possible
and then ensure that the nodes below it could rejoin the restarted BR. This
would mean that BR needs to backup some state information that would be
used post-crash-recovery.
On the contrary, in my scenario, it was necessary to detect 6LN/6LR failure
without depending on periodical pings from nodes to central sever i.e., for
some reason if the node (non-BR node) is stuck, then BR should detect it
asap (without depending on route lifetime since it could be very high) so
that measures could be taken (for e.g., send a personnel to repair the
smart meter). This also is non-trivial to handle. For BR, it is always
possible to ping on the external leg and check availability. Also, BR
unavailability means no traffic going out from any nodes and thus is easy
to identify on the external monitoring system.

Also, as Michael mentioned, the working group had discussed some issues
with respect to reboot handling (on 6LN/6LR/BR) and it has been captured in
https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/
It would be immensely helpful to get your view on those points.

Best,
Rahul

On Tue, 3 Mar 2020 at 00:42, Michael Richardson <[e-mail]>
wrote:

>
> Welcome!
>
> Konrad Iwanicki <[e-mail]> wrote:
>     > In a nutshell, I would like to propose an extension to RPL that had
> been
>     > invented to significantly improve handling crashes of border
> routers. Since I
>     > have little experience writing RFC-like drafts, I would greatly
> appreciate
>     > any help.
>
> Use the markdown method, and use someone's template github.
>
>     > What we observed, however, is that RPL does not efficiently handle
> crashes of
>     > border routers [1][2]. Upon such a failure, tearing down nonexistent
> upward
>     > routes can take a lot of time (depending on the data-plane traffic)
> and
>     > generate considerable control traffic, which is problematic in many
>     > applications.
>
> Rahul and Pascal (and others) have had a lot of conversation about how we
> deal with the various lollipop counters.  So I am interested in what your
> border router does when it boots: how does it announce the new DIOs?
>
>     > What we did to address the problem was developing an algorithm,
> called RNFD,
>     > in which nodes collaborate to monitor the state of a border router
> of the
>     > DODAG they belong to [1]. Experiments with a TinyOS implementation
> of the
>     > algorithm on two testbeds (32 nodes at 2.4GHz and 76 nodes at
> 868MHz) and in
>     > simulations show that it can outperform bare RPL: it can detect a
> border
>     > router crash one or two orders of magnitude faster and with much
> lower
>     > control traffic [1].
>
> okay.
>
>     > [1] K. Iwanicki: “RNFD: Routing-Layer Detection of DODAG (Root) Node
> Failures
>     > in Low-Power Wireless Networks,” in IPSN 2016: Proceedings of the
> 15th
>     > ACM/IEEE International Conference on Information Processing in Sensor
>     > Networks. IEEE. Vienna, Austria. April 2016. pp. 1—12. DOI:
>     > 10.1109/IPSN.2016.7460720
>
> Unfortunately, it's behind the IEEE paywall.
> I have given up on getting documents from the IEEE.
> I guess you have been working on this for at least five years now.
>
>     > [2] A. Paszkowska and K. Iwanicki: “Failure Handling in RPL
> Implementations:
>     > An Experimental Qualitative Study,” in Mission-Oriented Sensor
> Networks and
>     > Systems: Art and Science (Habib M. Ammari ed.). Springer
> International
>     > Publishing. Cham, Switzerland. September 2019. pp. 49—95. DOI:
>     > 10.1007/978-3-319-91146-5_3
>
>     > [3] P. Ciolkosz: “Integration of the RNFD Algorithm for Border
> Router Failure
>     > Detection with the RPL Standard for Routing IPv6 Packets,” Master's
> Thesis,
>     > University of Warsaw. November 2019.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>