Re: [Roll] capability vs. configuration

[Abdussalam Baryun <[e-mail]>]

On Mon, May 27, 2019 at 7:19 AM Li Zhao (liz3) <[e-mail]> 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 <[e-mail]
<[e-mail]>> on behalf of "Pascal Thubert (pthubert)"
<[e-mail] <[e-mail]>> Reply-To: Routing Over Low power
and Lossy networks <[e-mail] <[e-mail]>> Date: Monday, May 27,
2019 at 1:08 PM To: Routing Over Low power and Lossy networks
<[e-mail] <[e-mail]>> 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) <[e-mail] <[e-mail]>> 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 <[e-mail] <[e-mail]>>
Date: Saturday, May 25, 2019 at 9:18 AM To: Routing Over Low power and
Lossy networks <[e-mail] <[e-mail]>>, Li Zhao <[e-mail]
<[e-mail]>> 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 [e-mail] <[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll> *
>
>
>
>
>
>
> * _______________________________________________ Roll mailing list
> [e-mail] <[e-mail]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll> *