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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael:

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: mardi 7 juillet 2020 13:30
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07
> 
> 
> 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 :-)

Hopefully

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

Scenario 1 introduces a new OCP. There's text in RFC 6550 to force nodes to become leaves. 
This is why I'd like to see if the use cases may require 1) but not 2) or something.

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

Seems that we cannot use colours at all anymore anyway. Since I'm not native I'll take any word gracefully.



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

Since we are doing stuff for the current somewhat autumn field I'd like feedback on how that field is like.


> 
> 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 meant, I'd rather invest code implementing RFC 8138 than code to express the lack of capability to support it, and code to uncompress and recompress in the neighbors.
All in all it seems simpler that all MOP >7 support RFC 8138 as part of the RPLv2 certification. Capabilities to, but no point wasting one for this.



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

It was, but the autumn field has those nodes we do not want to hear about....

Take care,

Pascam