Re: [Roll] Border router failure detection

Konrad Iwanicki <> Thu, 17 March 2022 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B70603A00E0 for <>; Thu, 17 Mar 2022 06:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1a3CZgChS2ED for <>; Thu, 17 Mar 2022 06:35:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A37E3A00C4 for <>; Thu, 17 Mar 2022 06:35:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34BE0600FF060 for <>; Thu, 17 Mar 2022 14:35:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id Z_738HKjcJ-o for <>; Thu, 17 Mar 2022 14:35:03 +0100 (CET)
Received: from [] (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA for <>; Thu, 17 Mar 2022 14:35:02 +0100 (CET)
Message-ID: <>
Date: Thu, 17 Mar 2022 14:35:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
From: Konrad Iwanicki <>
To: Routing Over Low power and Lossy networks <>
Reply-To: Routing Over Low power and Lossy networks <>
References: <> <> <18233.1583176305@localhost> <> <> <> <> <> <> <> <> <8421.1620834368@localhost> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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 13:35:11 -0000

Dear all,

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. To this end, I went through our e-mails and meeting recordings 
and decided to just briefly summarize the status so far and propose some 
starting point.

# Status

RNFD is an addition to RPL that improves detecting crashes of DODAG 
roots by all DODAG members. The algorithm essentially boils down to 
nodes voting and achieving consensus on whether the root has crashed. 
The improvement regards only the performance and not the ability to 
detect root crashes: RPL alone can do this but the process is slow and 
generates heavy traffic.

 From our discussions, it seems that the problem seems important but the 
current RNFD algorithm is not necessarily the final one.

# Starting point

I am an author of the draft and it is hard for me to come up with a way 
to improve the algorithm. However, Pascal had an interesting idea, which 
may be worth exploring.

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. I think we could try to organize the initial work items 
around this idea to see if we can improve the RNFD algorithm or replace 
it with something else.

What do you think about this starting point?
Or perhaps do you have suggestions of other work items?

(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.)

- Konrad Iwanicki.