Re: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 04 June 2020 23:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D07BA3A1089 for <roll@ietfa.amsl.com>; Thu, 4 Jun 2020 16:57:40 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 cNY9O4qKZqCl for <roll@ietfa.amsl.com>; Thu, 4 Jun 2020 16:57:38 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06AA3A1080 for <roll@ietf.org>; Thu, 4 Jun 2020 16:57:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 24BD138A10 for <roll@ietf.org>; Thu, 4 Jun 2020 19:55:12 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fkArrEUAa2Ri for <roll@ietf.org>; Thu, 4 Jun 2020 19:55:11 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E7C9638A02 for <roll@ietf.org>; Thu, 4 Jun 2020 19:55:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 19C2F3D2 for <roll@ietf.org>; Thu, 4 Jun 2020 19:57:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <MN2PR11MB3565883F05AE0A0BD87AC416D8890@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MAXPR01MB24930DA521EA8B47F62CC6B3A9890@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM> <MN2PR11MB3565883F05AE0A0BD87AC416D8890@MN2PR11MB3565.namprd11.prod.outlook.com>
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: Thu, 04 Jun 2020 19:57:35 -0400
Message-ID: <11772.1591315055@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/dOnP6iNE7qHcFMeBgY4oSxOI5Ec>
Subject: Re: [Roll] Eliding-Info: Abbreviated Option and RCSS of an Option
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, 04 Jun 2020 23:57:41 -0000

{I feel I am increasingly distant from these things.  Too long since I wrote
code, I think}

Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
    > Well there is only one RCSS value that is monotonically incremented and
    > covers the whole DIO, with virtually all the options in it. The RCSS is
    > incremented each time one of the options changes.

    > The RCSS associated to the last change of a given option sticks to that
    > option. So when a node needs to know whether an option changed, it
    > looks for the RCSS of the last change for that option and compares with
    > the RCSS of the last change it is aware of. This is very similar to
    > using sequence counters is classical in db sync, e.g., in link state
    > protocols.

I feel a bit that maybe we are re-inventing a wheel here.
Maybe we should be doing more with DHCPv6?

Without really changing anything, I wonder if we should think of the AOO are
really just moving configuration out of the DIO into another place, and
rather than trickle flooding the configuration, we trick flood the
configuration reference.

Nodes without the new data need to fetch it.
Sometimes a 6LR will need to fetch that before a 6LR can move from leaf to router.
Maybe always.  Maybe if a flag is set.

What I'm trying to say here is that maybe we should thinking of the
configuration update process as a network service, which we happen to
leverage for network configuration, but also can be leveraged for application
configuration.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-