Re: [Roll] Border router failure detection

Michael Richardson <> Thu, 17 March 2022 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B78633A128E for <>; Thu, 17 Mar 2022 09:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j-UxpCORklCt for <>; Thu, 17 Mar 2022 09:55:03 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C851E3A1278 for <>; Thu, 17 Mar 2022 09:55:02 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 35A531F4BA for <>; Thu, 17 Mar 2022 16:49:08 +0000 (UTC)
Received: by (Postfix, from userid 179) id E80961A046F; Thu, 17 Mar 2022 11:32:40 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-reply-to: <>
References: <> <> <18233.1583176305@localhost> <> <> <> <> <> <> <> <> <8421.1620834368@localhost> <> <> <>
Comments: In-reply-to Konrad Iwanicki <> message dated "Thu, 17 Mar 2022 14:35:01 +0100."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 17 Mar 2022 11:32:40 -0400
Message-ID: <260038.1647531160@dooku>
Archived-At: <>
Subject: Re: [Roll] Border router failure detection
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Mar 2022 16:55:09 -0000

Konrad Iwanicki <> wrote:
    > Since the RNFD draft has been adopted by the group, I am expected to
    > propose a set of work items on which we could iterate to progress on
    > the draft.

Please note that it is an anti-pattern (a pathology) of the IETF that we
think that we have to improve/change the document after adoption.
It might be that there is little work to do, but we won't really know until
more people have read it.

    > More specifically, achieving consensus in RNFD is done in such a way
    > that the root node need not be involved. As long as the network remains
    > connected, the nodes are able to conclude that the root has crashed,
    > irrespective of how degenerated the DODAG may be because of the
    > crash. What Pascal suggested (or at least what I understood) is that
    > involving the root and using perhaps a different consensus algorithm
    > may be worth considering.

The idea being, I think, if the root hasn't crashed, it ought to be able to
quickly prove that to all parties involved.

The hidden node problem means that that some nodes might think that the root has
gone, when it is just not very reachable to that node.

A node that can speak to many other rank=2 ("root-children"?) nodes, but
can't see the root ought to just become a child of those other nodes.

    > (Also, I believe that discussing the work items should first be done
    > asynchronously/offline. However, if you prefer allocating a slot at
    > IETF 113, please do let me know.)

Discussion on the ML is always good and appropriate.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-