Re: [Roll] Border router failure detection
Konrad Iwanicki <iwanicki@mimuw.edu.pl> Thu, 08 April 2021 21:17 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 4CC5E3A1CBE for <roll@ietfa.amsl.com>; Thu, 8 Apr 2021 14:17:16 -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 jmk9TsEtVZMt for <roll@ietfa.amsl.com>; Thu, 8 Apr 2021 14:17:12 -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 E78F33A1CC6 for <roll@ietf.org>; Thu, 8 Apr 2021 14:17:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 0185A600A1A25; Thu, 8 Apr 2021 23:17:08 +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 9eHWJ2hThwmp; Thu, 8 Apr 2021 23:17:05 +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) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Thu, 8 Apr 2021 23:17:02 +0200 (CEST)
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "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> <27309.1617893979@localhost>
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
Message-ID: <4ab61b5f-c5f2-085b-beb6-26f4a67d8ca2@mimuw.edu.pl>
Date: Thu, 08 Apr 2021 23:17:01 +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: <27309.1617893979@localhost>
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/TNAoOybherbZlKM8wKkuFDtbpIU>
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:17:16 -0000
Hi Pascal, Michael, First of all, thanks for your interest, encouragement, and feedback! I'll try to answer in the "stack mode" (from your last email to the first) and as much as I can tonight because my throughput this week again became very limited due to another lockdown. On 08/04/2021 16:59, Michael Richardson wrote: > > Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote: > > 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. > > This works well for storing mode where one expects that all 6LR are pretty > much equivalently capable. > > For Non-Storing Mode, it could be that only the LBR (and it's redundant > backup...), are capable of accepting the DAOs, maintaining that table and > generating the right routing headers. > > Perhaps this is where the gap lies. Floating DODAGs are really the best option to keep routing inside a DODAG possible in the face of failures. RNFD, however, deals with an orthogonal problem and can actually help spawning floating DODAGs faster after a grounded DODAG's root dies, as I try to explain below. To start with, the envisioned use of RNFD concerns "important" DODAG roots (e.g., providing connectivity with the rest of the Internet) that in addition have an increased risk of failures (because of e.g. power supply interruptions or bugs resulting from greater HW/SW complexity compared to "normal" nodes). In practice, these will be LBRs that are roots of grounded DODAGs, and hence they are emphasized in the text. Nevertheless, one can use the algorithm also for any other DODAG roots. The cost is the overhead on DIOs and DISs due to the extra option and possible Trickle timer resets. Moreover, RNFD aims at minimal requirements with respect to RPL. In particular, it works even if a DODAG is completely degenerated. Likewise, it works for all RPL MOPs, notably even MOP 0 without any downward routes (which I believe is a particularly attractive feature). Therefore, regarding floating DODAGs, irrespective of nodes' capabilities, a major question is: When should a node leave a grounded DODAG and start advertising a floating one? More specifically, https://tools.ietf.org/html/rfc6550#section-18.2.4, quoted by Pascal in the previous e-mail, states that this is done by a node whose parent set becomes empty. And this moment is justified because---before---a node always has a possibility to select some node as the preferred parent. However, normally having an empty parent set implies that the node has already performed multiple unnecessary parent switches after a crash of the DODAG root, as the ranks of its subsequent parents grew repeatedly due to the lack of root. These switches must have taken time and generated control traffic resulting from Trickle timer resets. What RNFD can do is reduce the time from the crash of a DODAG root to the moment a node empties its parent set (which is done when RNFD sets its LORS to GLOBALLY DOWN) by an order of magnitude. This means that a node can much quicker conclude that the root node of a grounded DODAG is dead, empty its parent set, and start being the root of a floating DODAG. Note that this is independent of whether a storing or non-storing mode is utilized. What is more, this reduction of the root's crash detection period also reduces RPL's opportunities to switch the node's parents and degenerate downward routes in effect. Therefore, with RNFD it is likely that downward routes in the floating DODAG remain closer to what where in the original grounded DODAG, which is probably more important in a storing mode. To sum up, when operating together with RPL in a deployment where nodes can spawn floating DODAGs, RNFD can significantly reduce the interruption period of downward routing as well. What I see in the text of the draft is that indeed I did not mention the possibility of starting a floating DODAG when the GLOBALLY DOWN value of LORS is attained. Thanks a lot for these observations! Where do you think it would be best to put this information in the text? Best, -- - Konrad Iwanicki.
- [Roll] IETF 107: Call for presentations Ines Robles
- [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Rahul Jadhav
- Re: [Roll] Border router failure detection Ines Robles
- Re: [Roll] IETF 107: Call for presentations Remous-Aris Koutsiamanis
- Re: [Roll] IETF 107: Call for presentations Ines Robles
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] IETF 107: Call for presentations Rahul Jadhav
- Re: [Roll] IETF 107: Call for presentations Ines Robles
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] IETF 107: Call for presentations dominique.barthel
- Re: [Roll] IETF 107: Call for presentations Georgios Z. Papadopoulos
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Pascal Thubert (pthubert)
- Re: [Roll] Border router failure detection Pascal Thubert (pthubert)
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Pascal Thubert (pthubert)
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki
- Re: [Roll] Border router failure detection Michael Richardson
- Re: [Roll] Border router failure detection Konrad Iwanicki