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

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 12:28:37 -0500

Martin Duke <[email-masked]> 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.

    > Do I have this right?

I think so.

Finally, at present, there aren't many networks where there is much in the
way of multi-vendor nodes present.  That's sad.  But, the owners of the
networks want/need (often by NAFTA Article 10/etc. other treaty) to be able
to source from other vendors.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Nov 2020 14:49:10 -0800

> And we're okay with that, because it's the A/B -> C transition that

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.  Is it not accurate that node C could
interop with a MOP7-capable node, because C could be a leaf node? 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.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Nov 2020 18:27:28 -0500

>> And we're okay with that, because it's the A/B -> C transition that

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

    > 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,

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.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Martin Duke <[email-masked]>
Date: Wed, 11 Nov 2020 15:28:57 -0800

Very well.

On Wed, Nov 11, 2020 at 3:27 PM Michael Richardson <[email-masked]>
wrote:

>     >> > So I guess the value of the MOP 7 behavior is... to recover the
> bit
>     >> of the
>     >> > 1) If A is still out there when E deploys, this bit would have
> been
>     >> useful,
>     >> > but isn't.
>     >>