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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Jul 2020 16:13:25 +0000

Dear all

Alvaro raised an issue about

  1.  Why intermediate routers that do not support the compression have to be leaves
  2.  the decision to undo compression when delivering a packet to the destination, where the "knowledge" of support comes from
  3.  the relationship between this draft and the capabilities

We need your advice to move forward. Please bear with me and help us with arguments if you see reasons to go / nogo as proposed below:

For 1) I plan to clarify that we want to avoid compressing and decompressing on the way, so when RFC 8138 is turned on, one can be a router if and only if it can forward the compressed form. Without that rule, we'd need to know the support of the next hop before we forward in compressed form and we do not have that signaling (we'll need 3) for that).

With that rule, if the next hop is not the final destination, then it is a router and it supports the compressed format. So if there's an SRH that is not fully consumed when forwarding, the next hop supports the compression. This is a huge simplification, at least in non-storing mode.

Since  RPL does not signal a leaf from a router, when a router passes a packet to a child RAN in storing mode, the router does not know if this RAN owns the destination address so it does not know if it is a router so even with the rule above, it still cannot infer the support of compression.  Argl.

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.

If we MUST that the nodes that do not support the compression have to become RULs, then by definition all the RANs left support it. There is no more need to have a special "knowledge" of support about nodes. The parent knows it is delivering to a RUL, so it knows to undo compression if there's something left; usually there's nothing to do: there's a inner packet that is decapsulated and forwarded by the RUL's parent and that is not compressed with RFC 8138.

So with that additional rule:
Parent to child where child is RUL => decompress
Everywhere else => forward compressed

The corollary question to the group is whether we make the rule above specific to a storing mode DODAG, and in non-storing we say that the default is to uncompress once the SRH is fully consumed. Which one works best?

For 3) I think we should remove the discussion on the capabilities work from this draft. Capabilities are a RPLv2 feature (MOP>=7) whereas the turnon flag is only defined for RPLv1 (MOP<7). The capability can help to decide when to turn on, and that is earlier in the flow. The draft covers what happens when the decision is made.

When the capabilities infrastructure is available, if we decide to have a capability for RFC 8138, we can reconsider all the decisions above, whether a RAN can stay a RAL as opposed to a RUL when the compression is on and even whether we accept to decompress / recompress between routers. This would be a new design for RPLv2. But it might also be that we simply MUST the support of RFC 8138 with RPLv2, in which can we will not need a capability. That's a decision for the future, we do not need it now.

So do we agree to remove the reference to capabilities?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jul 2020 13:23:00 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> 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?

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

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

To determine that dynamically, we need capabilities.
What we have in this document is an operator controlled bit, not dynamic at
all.

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

I believe that the document has tried to do too many things.
Maybe just cut out everything that is not about that bit.
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"

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

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jul 2020 07:57:36 +0000

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 <[email-masked]> On Behalf Of Michael Richardson
> Sent: lundi 6 juillet 2020 19:23
> To: Routing Over Low power and Lossy networks <[email-masked]>; 'roll-
> [email-masked]' <[email-masked]>
> Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07
> 
> 
> 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.

> That's not the case, so we have jumped on this work to do "something".

True, that's this draft.

> 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

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

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

> 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

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 7 Jul 2020 08:39:45 +0000

Hello Pascal,

There is indeed real world indication for the scattered untouchable meters case. 

For instance, we should switch to  8138 instance from border router one by one in order to make millions of meters stable.
Meters MAY migrate from non-8138 instance to 8138 instance during the switch. 
These meters should operate as leaves and wait for further operation (maybe firmware upgrade).

Best regards,
Li

On 2020/7/7, 15:58, "Roll on behalf of Pascal Thubert (pthubert)" <[email-masked] on behalf of pthubert=[email-masked]> wrote:

    Hello Michael:

    True, that's this draft.

    Pascal

    _______________________________________________
    Roll mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 7 Jul 2020 09:34:43 +0000

<Pascal>

</Pascal>

<Rahul>
Even if there are thousands of nodes from an old brand, they will be within their own FAN (Field Area Network). The compression decision is on per Border-Router/Root level i.e., usually at a FAN level. Point is, all the millions shouldn't be impacted. My experience says that the firmware/meters in a given FAN are upgraded simultaneously. If a FAN contains a mix of old and new then it can continue using the uncompressed form.

I wish we could support all three types of leaves in the same network: RULs, RAL supporting compression, RAL not supporting compression, and all of this in both storing/non-storing. I also understand that the only problem case is the leaves in storing mode since the knowledge of last-hop is not known. But without additional changes in terms of introducing more fields, it may not be possible to handle this. The problem with these additional fields is that they will be redundant once we have capabilities.

I feel we do not need to handle the case of "forgotten nodes".
</Rahul>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 07:29:50 -0400

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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 07:31:14 -0400

Li Zhao \(liz3\) <liz3=[email-masked]> wrote:
    > For instance, we should switch to  8138 instance from border router one
    > by one in order to make millions of meters stable.

So you'd need a firmware upgrade before they could learn they need to be
leaves.  If you can eventually upgrade everything, then great.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 07:32:46 -0400

Rahul Jadhav <[email-masked]> wrote:
    >  The problem with these additional fields is that they will be
    >  redundant once we have capabilities.

    > I feel we do not need to handle the case of "forgotten nodes".

This.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jul 2020 13:00:18 +0000

Hello Michael:

> Sent: mardi 7 juillet 2020 13:30
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Cc: [email-masked]
> allow

Hopefully

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

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

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

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

> there are
> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jul 2020 13:10:04 +0000

> leaves.  If you can eventually upgrade everything, then great.

Not really. Our step 1) uses RFC 6550 mandates.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2020 12:06:43 +0000

OK, so how do we proceed?

1) I could remove it all; 
Or
2) I could keep the second scenario in appendix and explain that in NS mode we can use the compressed format to the penultimate hop.

What do you guys think?

Pascal

> Sent: mardi 7 juillet 2020 13:33
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 8 Jul 2020 12:51:47 +0000

1) remove it all;

My primary reason to say "Remove it all" is even in the non-storing mode we are dependent on 'E' bit to signal that the leaf node is RUL and does not support compression and I find it not appropriate, even though I do not have a scenario which will be impacted.

If we decide for 2) then better keep it as a different Section (something like "Handling 6LoRH unsupported nodes in Non-Storing mode") in the main text (not appendix).

________________________________
From: Roll <[email-masked]> on behalf of Pascal Thubert (pthubert) <pthubert=[email-masked]>
Sent: 08 July 2020 05:36 PM
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Roll] Alvaro's review on turnon Rfc 8138 07

What do you guys think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 10:28:55 -0400

> 1) remove it all;

+1

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2020 15:49:19 +0000

Done 😊

> Sent: mercredi 8 juillet 2020 16:29
>     > My primary reason to say "Remove it all" is even in the non-storing mode
> we are dependent on 'E' bit to signal that the leaf node is RUL and does not
> support compression and I find it not appropriate, even though I do not have a
> scenario which will be impacted.
> 
>     > If we decide for 2) then better keep it as a different Section (something like
> "Handling 6LoRH unsupported nodes in Non-Storing mode") in the main text
> (not appendix).

---

From: Ines Robles <[email-masked]>
Date: Wed, 8 Jul 2020 18:55:02 +0300

Hi Pascal,

Following my understanding, the action points are?:

- Deleting reference to capabilities from Introduction and (section 4?,
section 5.2? and section 5.3?)
- Clarifying behaviour in SM and Non-SM:

SM:

Parent to child where child is RUL ( including RAL  that does not
understand compression MUST acts as a RUL )=> decompress

Everywhere else => forward compressed (since it is assumed that
intermediate routers supports compression)

Non-SM:

The default is to uncompress once the SRH is fully consumed.

I understand that the ideal case would be turn on compression when all
nodes support it, but in real use cases could be nodes not supporting it
and must be part of the network anyway and the above it is to reflect how
to act on those cases.

Thank you in advance,

Ines.

On Wed, Jul 8, 2020 at 3:07 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> 2) I could keep the second scenario in appendix and explain that in NS
> mode we can use the compressed format to the penultimate hop.
>
> What do you guys think?
>
> Pascal
>

---

From: Ines Robles <[email-masked]>
Date: Wed, 8 Jul 2020 18:57:40 +0300

Ok, I got the new version,

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 15:56:41 -0400

Is there a github for this that I don't remember?
I am looking at the diff.  Thank for the changes.

There is a typo at:

  /[RFC6550] states, [RFC6550] states, when referring to the DODAG

If the root speaks RFC8138, but not turnon, and there are nodes which
support turnon and RFC8138, and the bit is missing, then 8138 won't get
turned on, right?

So the root is just another node which has to upgrade to support turnon,
right?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 8 Jul 2020 20:18:53 +0000

Hello Michael

Yes the git hub is https://github.com/roll-wg/roll-turnon-rfc8138.

There’s text about the root being capable of compression but not of setting the bit. In that case configuration or network management can override.

Many thanks again for your help, as always.

Pascal

Le 8 juil. 2020 à 22:01, Michael Richardson <[email-masked]> a écrit :

There is a typo at: