Re: [Roll] Border router failure detection

Konrad Iwanicki <iwanicki@mimuw.edu.pl> Tue, 18 October 2022 08:53 UTC

Return-Path: <iwanicki@mimuw.edu.pl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2972EC14CE2E for <roll@ietfa.amsl.com>; Tue, 18 Oct 2022 01:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZxKvbmKp3-4 for <roll@ietfa.amsl.com>; Tue, 18 Oct 2022 01:53:47 -0700 (PDT)
Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367EAC14CF0D for <roll@ietf.org>; Tue, 18 Oct 2022 01:53:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 115AF3000D618; Tue, 18 Oct 2022 10:53:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at duchn.mimuw.edu.pl
Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yFXf01Aid2RB; Tue, 18 Oct 2022 10:53:43 +0200 (CEST)
Received: from [10.12.6.132] (unknown [10.12.6.132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Tue, 18 Oct 2022 10:53:43 +0200 (CEST)
Message-ID: <ad97ce00-12a4-06b9-9e4f-db671056b326@mimuw.edu.pl>
Date: Tue, 18 Oct 2022 10:51:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <CAP+sJUfcEY2DNEQV=duJdN6P8zZn0ccuei+4ra-B6TcLb5z8Kg@mail.gmail.com> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <CO1PR11MB4881A5AA0E5C5010FD2BE39ED8749@CO1PR11MB4881.namprd11.prod.outlook.com> <bc174171-4b68-40b2-d532-463709e5bea8@mimuw.edu.pl> <CO1PR11MB4881D0C985582B28AE2DE8BED84E9@CO1PR11MB4881.namprd11.prod.outlook.com> <ab695952-3b11-46ad-f638-622ca770f8e1@mimuw.edu.pl> <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl> <8421.1620834368@localhost> <d0f9bd53-ed96-1512-5bc2-59063ba2d5dc@mimuw.edu.pl> <b556ca50-b2db-798f-1cf2-8d7a77d5ad63@mimuw.edu.pl> <21a67951-92c7-5cfa-7bda-a11ac004492c@mimuw.edu.pl> <260038.1647531160@dooku> <5fad2f45-02a5-7241-f797-43165b0fc9a2@mimuw.edu.pl> <386984.1649868259@dooku> <eed72f83-127a-8705-f956-d4765b967027@mimuw.edu.pl> <ca6c aa5f-a185-522d-6751-e3b5218acd43@mimuw.edu.pl> <26461.1665677140@localhost> <39e 6a070-c4f9-7fd1-8fad-310cf8726539@mimuw.edu.pl> <22337.1665750802@localhost>
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
In-Reply-To: <22337.1665750802@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/lxJQ_U7UnkGNIjan_YPkNbqKFP0>
Subject: Re: [Roll] Border router failure detection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2022 08:53:48 -0000

Hi Michael,

On 14/10/2022 14:33, Michael Richardson wrote:
> Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
>      > On 13/10/2022 18:05, Michael Richardson wrote:
>      >> Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
>      >> > 3. Is rebuilding the DODAG in such a case desirable?
>      >> > If the majority of links to the root that have once formed a DODAG
>      >> are
>      >> > currently down, then the DODAG should probably look different than for
>      >> > the network with those links up. Rebuilding the DODAG, at least in my
>      >> > opinion, makes a lot of sense in such a case. Furthermore, the threshold
>      >> > describing how large the majority is is configurable. Depending on whether
>      >> > one wants to prioritize speeding up root failure detection or slowing down
>      >> > DODAG rebuilding, different values can be chosen.
>      >> Do the sentinels need to agree on this threshold?
> 
>      > Yes, they should. This is a configuration parameter of the protocol.
> 
> I don't remember if this goes into the DIO or not.
> Should it?

I does not. I made it a parameter that is configured independent of the 
operation of the protocol. However, if necessary, it can go into the 
option itself.

> what is the effect of the parameter being different on different sentinels?
> (It's a pathological case, but worth thinking about for 30s)

The Sentinels or Acceptors (because the parameter is relevant for them 
as well) that have the lowest setting of the parameter will detect the 
crash the fastest and enforce their decision upon others.

> For me, I clearly should read the document again top to bottom, since it's
> been many months.  I guess I could volunteer to document shepherd.
> I think we should WGLC the document already.
> Perhaps in mid-November, I'll have time to finish debugging my RFC8994
> implementation.  I think that this protocol would be useful in the ACP case,
> but I'd be many months away from implementing.

Good luck then.

Best,
-- 
- Konrad Iwanicki.