Re: [Roll] Alvaro's review on turnon Rfc 8138 07

[Michael Richardson <[e-mail]>]

Pascal Thubert \(pthubert\) <pthubert=[e-mail]> wrote:
    > This is really useful, many thanks for contributing. I'll need more
    > from you and the WG, please see below;

    >> -----Original Message-----
    >> From: Roll <[e-mail]> On Behalf Of Michael Richardson
    >> Sent: lundi 6 juillet 2020 19:23
    >> To: Routing Over Low power and Lossy networks <[e-mail]>; 'roll-
    >> [e-mail]' <[e-mail]>
    >> Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07
    >>
    >>
    >> Pascal Thubert \(pthubert\) <pthubert=[e-mail]> wrote:
    >> > This takes us to 2) The above is why in the current text the leaf that
    >> > does not support the compression SHOULD act as a RUL, so it is an
    >> > external target and thus the default for it is to decompress before
    >> > forwarding. Alvaro and I are talking about MUSTing that, with the
    >> > argument that a RUL supporting the RPL compression looks like an
    >> > oxymoron.
    >>
    >> The problem is that this is a new rule (new code), and the point was to allow
    >> rfc8138 to be turned on without new code, right?

    > The RUL text only applies to a node that would have some new code but
    > not the support for compression.

I think this is a unicorn :-)

    > True, a legacy node cannot obey that. Which means that we can force it
    > to be a leaf but we cannot force it to be a RUL.

How can we force it to be a leaf without using a new MOP?

    >> This document is not supposed to accomodate old nodes: compression is either
    >> supported on every node, or not yet supported on every node.

    > Right. The document aims at enabling RFC 8138 in a brown field. The
    > *normal* scenario is migrate slowly the nodes with the bit off and when
    > all are migrated turn the bit on.

This is the upgrading brownfield case.
(Youtube has taught me that there is no such colour as "Brown". It's always
Dark Orange in context)
So, let's call this the "orangefield case"

    > The complex case is that of
    > "forgotten nodes", e.g., nodes for which there was never a new code for
    > this draft and for the compression, to try to serve them still. Imagine
    > a network where thousands of meters out of millions are from an old
    > brand that can never be upgraded. Can we replace them? Probably not. So
    > do we live with the idea that the compression can never be turned on in
    > the whole network?

I think that's the cost for having deployed things you can't upgrade :-)
   -> "Your lack of planning does not constitute an emergency for me"

But, I think that we can probably solve the case with capabilities, and possibly
new MOP values, but I don't see how, if we assume there are nodes that can
not get new code *AT ALL* that we can expect them to have a different
behaviour.

    > That's the big question to the group, is that a valid use case. Because
    > if it is, we do not want to have to do yet another draft do we?

I don't want this draft to solve it.
Just deal with orangefield case.

    > Yes, in the normal scenario, the benefit of capabilities would be to
    > ensure that all nodes are migrated. But if a node cannot be migrated,
    > the capabilities can also tell the parent to uncompress when forwarding
    > to this node. Life will be a lot simpler, though, if we mandate the
    > support of the compression in RPLv2. That means no configuration bit,
    > and no capabilities. Where's the best investment of code?

I think we need to design capabilities, we can deploy them with RPLv1,
and RPLv2 will simply be a marketing term that says the stack supports some
set of smarter capabilities by default.
I don't think we ever want a flag day.

    >> I believe it is a misconfiguration (operator error) to turn on rfc8138 if there are
    >> nodes that do not support it.  Just don't deal with that.

    > That would drop both the work for 1) and 2). That would simplify the
    > draft considerably. But we need to be careful, because if the case of
    > scattered untouchable meters is real then the compression can never be
    > turned on.

I think that we can turn compression on in parts of the network via
capabilities, but turnonrfc8138 was urgently needed for the orangefield situation.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-