Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 September 2020 01:35 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 D92D43A0A06; Wed, 9 Sep 2020 18:35:54 -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 tmXdwwXpt7aW; Wed, 9 Sep 2020 18:35:52 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60C03A0A03; Wed, 9 Sep 2020 18:35:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 78278389CD; Wed, 9 Sep 2020 21:14:39 -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 4IB2884ukksA; Wed, 9 Sep 2020 21:14:36 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 41672389CB; Wed, 9 Sep 2020 21:14:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3CB8FA94; Wed, 9 Sep 2020 21:35:47 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>, Routing Over Low power and Lossy networks <roll@ietf.org>
cc: "The IESG" <iesg@ietf.org>, roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-turnon-rfc8138@ietf.org
In-Reply-To: <159968972884.1065.3876077471852624744@ietfa.amsl.com>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.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: Wed, 09 Sep 2020 21:35:47 -0400
Message-ID: <14246.1599701747@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/cl5Vo8nwsqGDh0LediSNAKqhWc8>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
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, 10 Sep 2020 01:35:55 -0000

Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
    > The situation w.r.t. MOP values 5, 6, and 7 seems inconsistent to me.
    > We are not allocating them, but we are changing the RFC 6550 behavior
    > in the presence of at least one of them (but are not currently claiming
    > to Update 6550).  I have some further thoughts in the COMMENT section,

I don't know why we aren't Updating 6550.
That's news to me.  I had just assumed we were, and hadn't checked.
I should have.  I see that we are updating 8138, which itself does not update
6550, because 8138 deals with dataplane things only.

We are changing the RFC6550 behaviour in the presence of 0,1,2,3,4,5,6.
But, we are leaving the meaning of this bit when MOP=7 UNDEFINED, to be
defined in a future document.

In short: the bits are really valuable, and we want them back when we do what
we colloquially call "RPLv2".  Because every bit counts for this header that
is always present.

MOP is mostly the highest-level concept.
A node that does not know the MOP can participate as an RPL aware leaf.
(And we now admit RPL unaware leaves, aka "hosts" in another document)

We figure we might discover some horrible pathology in one of the other MOPs,
and we might need 5 or 6 to be able fix it quickly.

We are using MOP=7 as our escape to get more bits, and to let us remove
a decade of accumulated crud.  For instance, the in-band security stuff which
can never work, and which was published against my advice.

We will need a bit of time to get the mopex and planned capabilities sorted
right, and the set of people working on this stuff, and participating in the
IETF is unfortunately still small.

turnon-rfc8138 is the first document that really attempts to address
non-greenfield deployments!

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide