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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 11 November 2020 23:27 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 19CE63A11ED; Wed, 11 Nov 2020 15:27:33 -0800 (PST)
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 36d3cZ86tRao; Wed, 11 Nov 2020 15:27:31 -0800 (PST)
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 5A1BA3A11EC; Wed, 11 Nov 2020 15:27:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DF03389BA; Wed, 11 Nov 2020 18:28:00 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 97_wQd1k7j89; Wed, 11 Nov 2020 18:27:59 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C6BA389B5; Wed, 11 Nov 2020 18:27:59 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9D464EF4; Wed, 11 Nov 2020 18:27:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Martin Duke <martin.h.duke@gmail.com>
cc: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-turnon-rfc8138\@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "roll-chairs\@ietf.org" <roll-chairs@ietf.org>
In-Reply-To: <CAM4esxQ6w9_XN54gy-TR5RvzZwgmDwZ3GiXivmsMTN6CeBE5OQ@mail.gmail.com>
References: <6978.1605115717@localhost> <CAM4esxQ6w9_XN54gy-TR5RvzZwgmDwZ3GiXivmsMTN6CeBE5OQ@mail.gmail.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, 11 Nov 2020 18:27:28 -0500
Message-ID: <4890.1605137248@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/3YnohNlM65jTJSEFywQjAeRma6Y>
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: Wed, 11 Nov 2020 23:27:33 -0000

Martin Duke <martin.h.duke@gmail.com> wrote:
    >> Martin Duke <martin.h.duke@gmail.com> wrote:
    >> > So I guess the value of the MOP 7 behavior is... to recover the bit
    >> of the
    >> > flags? Fine, I suppose, but this would appear to have two costs:
    >> > 1) If A is still out there when E deploys, this bit would have been
    >> useful,
    >> > but isn't.
    >>
    >> The whole point is that A and E can't co-exist, BY CONSTRUCTION.
    >> The same way that IPv6 nodes can't talk to IPv4 directly.
    >> And we're okay with that, because it's the A/B -> C transition that
    >> worries us.

I'm sorry, the table was hard to read/remember, so maybe I should have said
"A/B can't co-exist with E"

    > I've already lifted the DISCUSS, but I am confused by this response. Yes,
    > in a perfect world all nodes are upgraded to implement this draft before
    > anyone ships anything with MOP7.

We are saying that, not just in a perfect world.
By construction, we saying that was are intentionally making this decision.
We have MOP 5 and MOP 6 still to allocate and possibly a bunch of other stuff
before we get to that place.

Again, IPv6 analogy: state "E" is when we turn off IPv4.
Any node not upgraded is landfill.  Sorry.

    > Is it not accurate that node C could
    > interop with a MOP7-capable node, because C could be a leaf node?

I think, yes.

    > If so,
    > then if A is still lying around then it can't even be a leaf node because
    > there's no way for E to run MOP7 without compression.

correct.
But... this is on 802.15.4 and other links where we use optionally use 8138 compression.
It wouldn't be true at all on 802.11 or ethernet links.
(Such as draft-ietf-anima-autonomic-control-plane's RPL instance)
Some new IP-over-FOO document where FOO != 802.15.4 [or lookalikes], could say
that 8138 was always on, or compression was unnecessary, or ...
Of course, device "A" probably won't have this new fangled as-yet-to-be-invented
interface, so it can't connect at layer-1 anyway.  If A if modular and can
grow such an interface, then I guess it better get a software update too.

    > Maybe it's true that A and B will all be gone, in which case my example is
    > true but irrelevant.


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