Re: [Roll] Border router failure detection

Konrad Iwanicki <iwanicki@mimuw.edu.pl> Thu, 08 April 2021 21:19 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 4B2663A1D22 for <roll@ietfa.amsl.com>; Thu, 8 Apr 2021 14:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xjb9ykYWpuk for <roll@ietfa.amsl.com>; Thu, 8 Apr 2021 14:19:38 -0700 (PDT)
Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E513A1D1D for <roll@ietf.org>; Thu, 8 Apr 2021 14:19:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 84FAD600A1A25; Thu, 8 Apr 2021 23:19:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at 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 JX7GSma31wH4; Thu, 8 Apr 2021 23:19:34 +0200 (CEST)
Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:446c:71a3:f6c4:59d5]) (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; Thu, 8 Apr 2021 23:19:34 +0200 (CEST)
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
References: <CAP+sJUfcEY2DNEQV=duJdN6P8zZn0ccuei+4ra-B6TcLb5z8Kg@mail.gmail.com> <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <CAO0Djp3w4vWCOawQ+eegNTRzb_HRGYH6n=bdEH6iVf5ZO0AGFQ@mail.gmail.com> <f71fe153-c0d1-097e-a72e-49ece97cbd48@mimuw.edu.pl> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <CO1PR11MB4881A5AA0E5C5010FD2BE39ED8749@CO1PR11MB4881.namprd11.prod.outlook.com>
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
Message-ID: <bc174171-4b68-40b2-d532-463709e5bea8@mimuw.edu.pl>
Date: Thu, 8 Apr 2021 23:19:33 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CO1PR11MB4881A5AA0E5C5010FD2BE39ED8749@CO1PR11MB4881.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/ibB8sVvVYraesUHRxS-0Unmou7Y>
Subject: Re: [Roll] Border router failure detection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 08 Apr 2021 21:19:43 -0000

Hi again Pascal,

On 08/04/2021 16:16, Pascal Thubert (pthubert) wrote:
> Hello Konrad
> 
> About this text
> "
> 
>     Since all DODAG paths lead to the corresponding LBR, detecting its
>     crash by a node entails dropping all parents and adopting an infinite
>     rank, which reflects the node's inability to reach the LBR.  However,
>     achieving this state for all nodes is slow, can generate heavy
>     traffic, and is difficult to implement correctly [Iwanicki16]
>     [Paszkowska19] [Ciolkosz19].
> "
> 
> Please note that this may be what an implementation decides to do, but is by far not my favorite option.
> The alternate is to rest the "G" but and become floating root. The benefit is that the DODAG structure is mostly maintained and that routing inside may persist.
> 
> See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to configure this.

OK, I think I addressed this in my previous e-mail to you and Michael.

(The next two e-mails will have to wait till tomorrow I am affraid.)

Best,
-- 
- Konrad Iwanicki.

>> -----Original Message-----
>> From: Roll <roll-bounces@ietf.org> On Behalf Of Konrad Iwanicki
>> Sent: mercredi 7 avril 2021 21:37
>> To: Routing Over Low power and Lossy networks <roll@ietf.org>
>> Subject: Re: [Roll] Border router failure detection
>>
>> Dear all,
>>
>> Approximately a year ago, I joined the WG and advertised an extension to
>> RPL that I had been working on for some time with a goal of describing it
>> in a draft. Unfortunately, just when I got the necessary pointers and a
>> few initial comments, the pandemic broke out. The resulting surge of
>> professional and personal obligations made it literally impossible for me
>> to participate in and, at some point, even follow the group's activities,
>> for which I am sorry.
>>
>> However, I did strive to regularly find a little time to get somewhat
>> acquainted with IETF's procedures and write up something that may resemble
>> a draft. I have just submitted it as:
>>
>>      draft-iwanicki-roll-rnfd-00
>>
>> and created a dedicated repository on the group's GitHub.
>>
>> Since I have no experience writing IETF documents, I would really
>> appreciate your collaboration on either turning the text into a true draft
>> or concluding that this should not be done.
>>
>> Please, keep mind in mind that I decided to maximally cut down the
>> original algorithms, so that the extension is as simple as possible
>> without losing key properties. Therefore, it is likely that if the
>> extension as a whole or any of its parts turn out relevant or interesting,
>> still a considerable amount of work may be necessary to have it or them
>> described properly. Your contribution is most welcome.
>>
>> Thanks in advance.
>>
>> Best regards,
>> --
>> - Konrad Iwanicki.
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>