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

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

Hello Michael:

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.
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.
We can protect that legacy node in non-storing mode by forcing that the last hop must be uncompressed, e.g., with a configuration knob. 
That's the special knowledge the doc talks about. The text defaults that if we do not have a special knowledge the last hop must be uncompressed.
The trouble is with storing mode. We never know when it's the last hop. So we cannot uncompress, and the RAL will be cut off. Unless we have special knowledge that the RAL does not support the compression. This kinda reverse the situation vs. non-storing. I believe I need a section to explain all that.

> 
> When we did RFC8138, it was stated that it would get deployed in greenfields
> only, and that we didn't need signaling.
> That's not the case, so we have jumped on this work to do "something".

True, that's this draft.

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

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?

Note that if there are too many of them, turning them into leaves will kill the network anyway. This is why we have the 2 instances scenario.

> To determine that dynamically, we need capabilities.

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?


> What we have in this document is an operator controlled bit, not dynamic at
> all.

Yes. And management to decide if all nodes are migrated as opposed to capabilities. That works.

> I'm not sure when it mutated it's purpose :-)

Not really mutated but added work beyond the *normal* scenario to accommodate some non-migrated nodes by 1) making them leaves so they do not blackhole the network and 2) trying to find way to detect them so the parent can uncompress. 
 
> I believe that the document has tried to do too many things.
> Maybe just cut out everything that is not about that bit.

I understand here that you find that 2) above may be excessive. Text below indicates that you find 1) excessive too. 

> For instance, section 5, paragraph 3:
> 
>    If the
>    compression is turned on, the node cannot forward compressed packets
>    and therefore it cannot act as a router.
> 
> should just say, "the node/network fails"

If we do not make the node a leaf doing 1) then yes, the network fails. If we do 1 but not 2) only the node fails.


> >   To ensure that a packet is forwarded across the RPL Instance in the
> >   form in which it was generated, it is required that all the routers
> >   support [RFC8138] at the time of the switch, and that all nodes that
> >   do not support [RFC8138] only operate as leaves.
> 
> 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.

WG: Do we have some real world indication for this?

Pascal