Subject: Re: [Roll] capability vs. configuration

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 27 May 2019 03:23:50 +0000

In order to decide whether  it can safely set the config flags, it would be good that the root knows about the node capabilities such as route projection, RFC 8138 compression and option x23 for RPI. So I thought that the node could expose that capability using mop-ext and we add the bits in the draft already.

[RJ] So the root is expected to set the T-flag after learning the nodes capabilities after the initial DIO-DAO round .. is this right? i.e. once the root learns that all nodes are 8138 capable then it sets the T-flag in the subsequent DIO (possibly after DTSN increment)? What happens if a node springs up later and announces that it does not support 8138 after the T-flag was turned on by the root ?

[Li] How to identify the initial DIO-DAO round is also a problem to deal with. Because the root doesn’t know the scalability/max hop/form time of each PAN.
One propose is adding scalability/form time as capability of root, root can detect initial DIO-DAO and then announces 8138 or option x23 to nodes.

[RJ]  What happens if a non-8138 compatible node springs up later (i.e., after root has announced T-flag set in DIO) and advertises that it is not 8138 capable ? Would root in turn start updating the network to reset T-flag in DIO? In this case there could be 8138 compressed traffic in-transit while the unsetting of T-flag is in progress.

[Li] The mixed 8138 and non-8138 network should not be common case when deployment. It’s usually existing during upgrading firmware. Dynamic switch 8138/non-8138 by root is not a good idea.
If it’s indeed a mixed network, two instances(one for 8138 and another for non-8183) is a workaround.

For route projection, we could include a number of routes that the node can store, using a number like 10 hops max for non-storing PDAOs.

[RJ] Yes this could be done and will help route projection.

[Li] In non-storing PDAO, the route entries number and max hops are both needed as capabilities.

Best regards,
Li

From: Rahul Arvind Jadhav <[email-masked]<mailto:[email-masked]>>
Date: Saturday, May 25, 2019 at 9:18 AM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>, Li Zhao <[email-masked]<mailto:[email-masked]>>
Subject: RE: capability vs. configuration

As you know, we have a configuration option in standard RPL. It is used by useofrplinfo to trigger the use of option x23 and by https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00 to trigger the use of RFC 8138 compression.

This must not be confused with the capability draft in draft-rahul-roll-mop-ext which is how the nodes and the root share on what capabilities they have. A configuration is a flat order from the root, the capability is an exchange of information.

[RJ] By flat order, I assume you mean that all the nodes either support it or they don’t. There are no mixed nodes. In this case, yes, this is a candidate for existing configuration option rather than capabilities. I read the draft and I believe this to be true.

In order to decide whether  it can safely set the config flags, it would be good that the root knows about the node capabilities such as route projection, RFC 8138 compression and option x23 for RPI. So I thought that the node could expose that capability using mop-ext and we add the bits in the draft already.

[RJ] So the root is expected to set the T-flag after learning the nodes capabilities after the initial DIO-DAO round .. is this right? i.e. once the root learns that all nodes are 8138 capable then it sets the T-flag in the subsequent DIO (possibly after DTSN increment)? What happens if a node springs up later and announces that it does not support 8138 after the T-flag was turned on by the root ?

For route projection, we could include a number of routes that the node can store, using a number like 10 hops max for non-storing PDAOs.

[RJ] Yes this could be done and will help route projection.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 05:07:53 +0000

Hello Li

I do not understand your point that the capability to switch to 8138 is not a good idea.
I understand it is better to avoid the situation but sometimes you have no choice. And if you upgrade a first node in the middle of the network then there are no parent to form a dodag.

Bottom line is you upgrade all your nodes and then you set the flag in the capability.

What do I miss?

Regards,

Pascal

Le 27 mai 2019 à 05:24, Li Zhao (liz3) <[email-masked]<mailto:[email-masked]>> a écrit :

Best regards,
Li

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

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 27 May 2019 05:18:45 +0000

Hello Pascal,

My point is that dynamic switch the capability too frequently or too easily is not good. At least we need some rule to limit the switch capability.

For example, if a root forms a network with 1000 nodes which supports 8183. What should root do when it receives a non-8138 compatible DAO? Reject this node or switch the whole network to non-8138. It’s hard to decide by root itself.

Best regards,
Li

From: Roll <[email-masked]> on behalf of "Pascal Thubert (pthubert)" <[email-masked]>
Reply-To: Routing Over Low power and Lossy networks <[email-masked]>
Date: Monday, May 27, 2019 at 1:08 PM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] capability vs. configuration

Hello Li

What do I miss?

Regards,

Pascal

Best regards,
Li

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 06:36:38 +0000

Hello Li

I think we agree and I think you still support the turnon_8138 draft. In more details: the flag is useful in a transition till all nodes are converted to ensure a continuity of operation during a transition.

A network with the flag off and hybrid support works. When all nodes support RFC 8138 and as the new config spreads only a few saw the flag things still work, you’ll see packets of both types but all will be forwarded.
But rolling back the flag is not guaranteed to work fully before a long time since a node here and there may still be missing the update of the DIO and keep on using RFC 8138.

I think that what is true there is true also for useofrplinfo. The flag is used to delay the use of the new feature till the flag day. Once the flag day is passed, that’s it for all.

The capability is good to reassure the admin that all nodes are upgraded and ready. If after that the admin deploys  a back level node, his mistake.

Now we can work on minimizing the damage. E.g. we can add text to say that a child cannot forward an RFC 8138 via a parent that does not set the flag. But then, we’d need the parent to express his capability and that’s again an interaction with the capability draft. Note that the parent cannot change the config option and must forward it as is, whether it understands it or not.

Also, the root must encaps with RFC 8138 only along a path that is known to support it. E.g., if the child does not then the root can encapsulate to the parent ip in ip, and leave native RFC 6775 in the inner packet.

Doe sthat look good ?

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: lundi 27 mai 2019 07:19
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] capability vs. configuration

Hello Pascal,

Best regards,
Li

From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Reply-To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 27, 2019 at 1:08 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] capability vs. configuration

Hello Li

What do I miss?

Regards,

Pascal

Best regards,
Li

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 07:15:51 +0000

Hello Li:

<PT>The idea is that the admin decides at some point to do the switch, after the network has been up and operational, nodes have ben upgraded if needed, etc. Eventually all nodes are ready, the flags confirm that, and the admin presses the button. Over the next minutes, hours or days, the network will convert while never stopping, at least that is the goal of the draft. We could have a section on applicability, if you are willing to write it, Li?

<PT> I agree that going back is a bad idea. This is supposed to be used for flag day.

<PT> Works for me.

All the best,

Pascal

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 27 May 2019 07:26:13 +0000

Hello Pascal:

[Li] Agree with you. I’ll write up the section about applicability.

Best regards,
Li

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 27 May 2019 07:45:12 +0000

Hello Pascal,

Flag day idea looks good for me. And we should note two points:

  1.  Some battery node need long time to sync flag day from DIO
  2.  Some node doesn’t have UTC time. Maybe we should use time drift to identify flag day?

Best regards,
Li

Date: Monday, May 27, 2019 at 2:37 PM

Hello Li

Doe sthat look good ?

Pascal

Hello Pascal,

Best regards,
Li

Hello Li

What do I miss?

Regards,

Pascal

Best regards,
Li

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 07:51:20 +0000

Hello Li:

The draft is written so that we can live with node that have seen the flags and nodes that have not seen it, as long as all nodes support RFC 8138.
The point is that a node must keep the packet in its form, compressed or not, so the format of the packet will only depend on whether the source saw the flag or not.
IOW nodes always accept to process a packet that is encoded with RFC 8138, but they can only source such a packet if they saw the flag.

We could have text to clarify that as well in the applicability.

Does that work for you?

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: lundi 27 mai 2019 09:45
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] capability vs. configuration

Hello Pascal,

Best regards,
Li

Hello Li

Doe sthat look good ?

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Li Zhao (liz3)
Sent: lundi 27 mai 2019 07:19
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] capability vs. configuration

Hello Pascal,

Best regards,
Li

Hello Li

What do I miss?

Regards,

Pascal

Best regards,
Li

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 27 May 2019 10:31:40 +0200

On Mon, May 27, 2019 at 7:19 AM Li Zhao (liz3) <[email-masked]> wrote:

> Hello Pascal,
>
> *   My point is that dynamic switch the capability too frequently or too
> easily is not good. At least we need some rule to limit the switch
> capability.*
>

I think it is better to have no switch of capability at all times, that is
more stable for the network, we need to ensure stability and reliability.

> *   For example, if a root forms a network with 1000 nodes which supports
> 8183. What should root do when it receives a non-8138 compatible DAO?
> Reject this node or switch the whole network to non-8138. It’s hard to
> decide by root itself. *
>

the idea of changing capability makes things complicated without important
outcomes.

AB

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *     Best regards, Li   From: Roll <[email-masked]
<[email-masked]>> on behalf of "Pascal Thubert (pthubert)"
<[email-masked] <[email-masked]>> Reply-To: Routing Over Low power
and Lossy networks <[email-masked] <[email-masked]>> Date: Monday, May 27,
2019 at 1:08 PM To: Routing Over Low power and Lossy networks
<[email-masked] <[email-masked]>> Subject: Re: [Roll] capability vs.
configuration   Hello Li   I do not understand your point that the
capability to switch to 8138 is not a good idea. I understand it is better
to avoid the situation but sometimes you have no choice. And if you upgrade
a first node in the middle of the network then there are no parent to form
a dodag.    Bottom line is you upgrade all your nodes and then you set the
flag in the capability.   What do I miss?     Regards,   Pascal Le 27 mai
2019 à 05:24, Li Zhao (liz3) <[email-masked] <[email-masked]>> a écrit : In
order to decide whether  it can safely set the config flags, it would be
good that the root knows about the node capabilities such as route
projection, RFC 8138 compression and option x23 for RPI. So I thought that
the node could expose that capability using mop-ext and we add the bits in
the draft already.   [RJ] So the root is expected to set the T-flag after
learning the nodes capabilities after the initial DIO-DAO round .. is this
right? i.e. once the root learns that all nodes are 8138 capable then it
sets the T-flag in the subsequent DIO (possibly after DTSN increment)? What
happens if a node springs up later and announces that it does not support
8138 after the T-flag was turned on by the root ?   [Li] How to identify
the initial DIO-DAO round is also a problem to deal with. Because the root
doesn’t know the scalability/max hop/form time of each PAN. One propose is
adding scalability/form time as capability of root, root can detect initial
DIO-DAO and then announces 8138 or option x23 to nodes.   [RJ]  What
happens if a non-8138 compatible node springs up later (i.e., after root
has announced T-flag set in DIO) and advertises that it is not 8138 capable
? Would root in turn start updating the network to reset T-flag in DIO? In
this case there could be 8138 compressed traffic in-transit while the
unsetting of T-flag is in progress.   [Li] The mixed 8138 and non-8138
network should not be common case when deployment. It’s usually existing
during upgrading firmware. Dynamic switch 8138/non-8138 by root is not a
good idea. If it’s indeed a mixed network, two instances(one for 8138 and
another for non-8183) is a workaround.   For route projection, we could
include a number of routes that the node can store, using a number like 10
hops max for non-storing PDAOs.   [RJ] Yes this could be done and will help
route projection.   [Li] In non-storing PDAO, the route entries number and
max hops are both needed as capabilities.   Best regards, Li     From:
Rahul Arvind Jadhav <[email-masked] <[email-masked]>>
Date: Saturday, May 25, 2019 at 9:18 AM To: Routing Over Low power and
Lossy networks <[email-masked] <[email-masked]>>, Li Zhao <[email-masked]
<[email-masked]>> Subject: RE: capability vs. configuration   As you know,
we have a configuration option in standard RPL. It is used by useofrplinfo
to trigger the use of option x23 and by
https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00
<https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00> to
trigger the use of RFC 8138 compression.   This must not be confused with
the capability draft in draft-rahul-roll-mop-ext which is how the nodes and
the root share on what capabilities they have. A configuration is a flat
order from the root, the capability is an exchange of information.   [RJ]
By flat order, I assume you mean that all the nodes either support it or
they don’t. There are no mixed nodes. In this case, yes, this is a
candidate for existing configuration option rather than capabilities. I
read the draft and I believe this to be true.   In order to decide whether
it can safely set the config flags, it would be good that the root knows
about the node capabilities such as route projection, RFC 8138 compression
and option x23 for RPI. So I thought that the node could expose that
capability using mop-ext and we add the bits in the draft already.   [RJ]
So the root is expected to set the T-flag after learning the nodes
capabilities after the initial DIO-DAO round .. is this right? i.e. once
the root learns that all nodes are 8138 capable then it sets the T-flag in
the subsequent DIO (possibly after DTSN increment)? What happens if a node
springs up later and announces that it does not support 8138 after the
T-flag was turned on by the root ?   For route projection, we could include
a number of routes that the node can store, using a number like 10 hops max
for non-storing PDAOs.   [RJ] Yes this could be done and will help route
projection.   _______________________________________________ Roll mailing
list [email-masked] <[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll> *
>
>
>
>
>
>
> * _______________________________________________ Roll mailing list
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll> *

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 10:38:46 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > I think that what is true there is true also for useofrplinfo. The flag is
    > used to delay the use of the new feature till the flag day. Once the flag day
    > is passed, that’s it for all.

That's not the correct usage of the term "flag day", and I think your usage
causes confusion!

A *Flag Day* is one where one turns off the network, reconfigures it, and
restarts cold.  It's not the day that the configuration (flag) value is set
:-)

    https://en.wikipedia.org/wiki/Flag_day_(computing)
    This systems terminology originates from a major change in the Multics
    operating system's definition of ASCII, which was scheduled for the United
    States holiday, Flag Day, on June 14, 1966.

note that it's called "Flag Day" because of when it occured (on a specific
holiday), not because flags were changed.

====

The configuration option in the DAO allows the network to reconfigure without
being turned off.

The purpose of each of these configuration options is to keep more capable
nodes from using their capabilities until all nodes are upgraded.
In effect, one can always choose not to compress,  and this is why 8138 is
lossy compression rather than subIP.

This means nodes have to be able to process without 8138, and that means more code :-(

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 14:52:55 +0000

I see. 

Which means that if we have a real flag day then we do not need the config flag in the config option. 
The flag is really useful in the transient phase where nodes are capable of the feature but not using it yet till all are capable.
That was the initial thought but then (big surprise) we found that operational people do not want to bring down a network of 1000s of nodes, reflash them and then reboot it all fingers crossed.
What they can do is reflash over the air and then restart the devices asynchronously, keeping the network globally alive.
This is what triggered the need for the configuration flag. I think the same applies to useofrplinfo, which also justifies the config bit there. 

But then "flag day" should not be used in either spec should it?

All the best,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: lundi 27 mai 2019 16:39
> The configuration option in the DAO allows the network to reconfigure
> without being turned off.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2019 10:24:12 -0400

> config flag in the config option.

exactly. One might have to visit every single node (truck roll) and tweak
each system.   So I'd write it:

    } The 8138-enable-option in the configuaration option prevents Flag Days
    } that might otherwise include truck rolls.

    > What they can do is reflash over the air and then restart the devices
    > asynchronously, keeping the network globally alive.

    > This is what triggered the need for the configuration flag. I think the
    > same applies to useofrplinfo, which also justifies the config bit
    > there.

    > But then "flag day" should not be used in either spec should it?

Yes, the config option avoids the need for a Flag Day.