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

[Martin Duke <[e-mail]>]

Very well.

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

>
> Martin Duke <[e-mail]> wrote:
>     >> Martin Duke <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>