Re: [Roll] Border router failure detection

Michael Richardson <> Wed, 07 April 2021 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 417E03A2EDE for <>; Wed, 7 Apr 2021 16:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePK3sWQTA7GO for <>; Wed, 7 Apr 2021 16:46:28 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CC4F3A2EDD for <>; Wed, 7 Apr 2021 16:46:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FDB638FD8 for <>; Wed, 7 Apr 2021 19:53:16 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id WqwZMh1KWSgC for <>; Wed, 7 Apr 2021 19:53:15 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 16C3B38FD7 for <>; Wed, 7 Apr 2021 19:53:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 249C348B for <>; Wed, 7 Apr 2021 19:46:24 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-Reply-To: <>
References: <> <> <18233.1583176305@localhost> <> <> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 07 Apr 2021 19:46:24 -0400
Message-ID: <8372.1617839184@localhost>
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: Wed, 07 Apr 2021 23:46:33 -0000

Konrad Iwanicki <> wrote:
    > draft. Unfortunately, just when I got the necessary pointers and a few
    > initial comments, the pandemic broke out.

I know the feeling.
I keep thinking I should be able to do *more* since I can't go out.

    > draft-iwanicki-roll-rnfd-00

    > and created a dedicated repository on the group's GitHub.

I see it at:

You might want to add a Makefile, either via
or rip of my minimal one, such as:

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

It looks like you did a really good job.

RPL is being used in storing mode the ANIMA WG's Autonomic Control Plane.
( section 6.12. ).   The document is minutes away from getting an RFC#.

We think that the border router, DODAG root, will be a device in the NOC.
The NOC may get replicated into multiple locations so there could potentially
be more than one candidate DODAG root.  Given nodes are not constrained in
the RFC7228 sense, supporting multiple DODAGs could be done, but we
simplified our life by not mandating (actually, at this point, forbidding)
the RPI header, so we are lacking an instanceID.

The short of it is that I'd really like nodes to be able to float
non-grounded DODAG roots if they don't hear a DIO after a few seconds.


It seems that you might want a term for the LBR's children.
That is, the devices at rank "1", that hear the LBR's DIOs.

I think that I would move some of section 3.2 further forward in the
document.  I think that I need a gentler introduction to CFRCs here, and I
don't really need to know the properties, rather I need a higher-level idea
of things.    Since section 4 goes over the operations again, I would leave
it for that spot, and make it a section 4.1.

Having gone forward and back a bit, I'm still a bit uncertain how nodes
assign themselves a bit... oh, self() in section 4 says "random".
Why not make this a function (hash?) of the short-IPv6 address or something?

Not every media has ACK frames at the L2 to establish that there are
failures.  It might be worth putting the Detecting and the Verifying into
separate sections.  Aside from the ANIMA case (which is usually pure ethernet),
there are also situations where there is an ethernet backbone connecting a
few 6LBRs (RFC8929), and your protocol would sensibly run on both the
wireless and the wired side of the 6LBRs.

I also wonder if the RNFD could be included in DAOs (particularly storing
mode ones) sent to the DODAG root.
I know that probably seems senseless: why tell the root that you are
observing it to be dying....  But, it acts as interesting telemetry about
what the nodes are seeing, and might serve as a useful indication of imminent
failure, or some kind of systematic long-cycle pathology.

Your IANA considerations are how the document will look after IANA has
processed it.  Prior to that point, you need to write it as a request.

Something like:

   IANA is requested to allocate the value TBD1 from the "RPL Control Message
   Options" sub-registry of the "Routing Protocol for Low Power and Lossy
   Networks (RPL)" registry.

I like to include the URL of the registry in my request to be really really
clear, and to save everyone else the time to find it.

Your security considerations will want to cite RFC7416.
In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant.

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide