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 =-
- [Roll] Eliding-Info: Abbreviated Option and RCSS … Rahul Jadhav
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Li Zhao (liz3)
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Rahul Jadhav
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Pascal Thubert (pthubert)
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Pascal Thubert (pthubert)
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Rahul Jadhav
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Michael Richardson
- Re: [Roll] Eliding-Info: Abbreviated Option and R… Rahul Jadhav