Re: [Roll] Add ROVR in DAO?

Michael Richardson <> Mon, 26 August 2019 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 990AE120992 for <>; Mon, 26 Aug 2019 09:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bqF1f2YiHlUR for <>; Mon, 26 Aug 2019 09:31:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC1CB1200DF for <>; Mon, 26 Aug 2019 09:31:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 548BE3818C for <>; Mon, 26 Aug 2019 12:30:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6743289 for <>; Mon, 26 Aug 2019 12:31:36 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Mon, 26 Aug 2019 12:31:36 -0400
Message-ID: <4624.1566837096@localhost>
Archived-At: <>
Subject: Re: [Roll] Add ROVR in DAO?
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: Mon, 26 Aug 2019 16:31:41 -0000

Pascal Thubert (pthubert) <> wrote:
    > Note that I do not know how to avoid keeping what we have in unaware
    > leaves today, that is the flow from the 6LR without a ROVR, and the
    > problem is as usual backward compatibility.

I'll need to spend some time with some flows in front of me to understand the conflict.
unaware leaves is not done, and not deployed, so can we just change it now
It's a bit of a mirky swirl of time sequence diagrams for me right now.

    > We have to chose between yet another flag day / configuration bit
    > approach or to live with the keep alive as already described with no
    > ROVR as an option.

    > There's also the problem of knowing whether the 6LBR supports the keep
    > alive with no ROVR. That will need to be signaled.

I feel there is a combinatorics of options here, and not a lot of ability to
communicate them to RULs.   Let's get the end point well described, and
figure out if there are in fact way points in the middle which are worth
while describing?

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-