IETF Logo Mail Archive

Re: [Roll] capability vs. configuration

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 27 May 2019 14:38 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 90766120170 for <roll@ietfa.amsl.com>; Mon, 27 May 2019 07:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZujvB_gWSfo for <roll@ietfa.amsl.com>; Mon, 27 May 2019 07:38:48 -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 8F6C012015F for <roll@ietf.org>; Mon, 27 May 2019 07:38:48 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 01073380BE for <roll@ietf.org>; Mon, 27 May 2019 10:37:44 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1288AF39; Mon, 27 May 2019 10:38:46 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FD86B93 for <roll@ietf.org>; Mon, 27 May 2019 10:38:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <MN2PR11MB356549E5AB3B8CFDC7249465D81D0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <A587F9B0-9F1A-4307-9D3E-C261D6EF566A@cisco.com> <6E26B721-36DF-4B0D-8930-3F90179D557B@cisco.com> <87C818D7-A6D2-466D-9E74-3FBFCBD812F9@cisco.com> <MN2PR11MB356549E5AB3B8CFDC7249465D81D0@MN2PR11MB3565.namprd11.prod.outlook.com>
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, 27 May 2019 10:38:46 -0400
Message-ID: <21535.1558967926@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/v2j7caZtLUeLAsWmrHQpA-iWNYY>
Subject: Re: [Roll] capability vs. configuration
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: Mon, 27 May 2019 14:38:50 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > I think that what is true there is true also for useofrplinfo. The flag is
    > used to delay the use of the new feature till the flag day. Once the flag day
    > is passed, that’s it for all.

That's not the correct usage of the term "flag day", and I think your usage
causes confusion!

A *Flag Day* is one where one turns off the network, reconfigures it, and
restarts cold.  It's not the day that the configuration (flag) value is set
:-)

    https://en.wikipedia.org/wiki/Flag_day_(computing)
    This systems terminology originates from a major change in the Multics
    operating system's definition of ASCII, which was scheduled for the United
    States holiday, Flag Day, on June 14, 1966.

note that it's called "Flag Day" because of when it occured (on a specific
holiday), not because flags were changed.

====

The configuration option in the DAO allows the network to reconfigure without
being turned off.

The purpose of each of these configuration options is to keep more capable
nodes from using their capabilities until all nodes are upgraded.
In effect, one can always choose not to compress,  and this is why 8138 is
lossy compression rather than subIP.

This means nodes have to be able to process without 8138, and that means more code :-(

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

v2.23.0 | Report a Bug | By Email