IronPort-PHdr: =?us-ascii?q?9a23=3ARHwFixA6oBzZTNR0eiEbUyQJPHJ1sqjoPgMT9p?=
 =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?=
 =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?=
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] do capabilities need to understood, can they be added?
Thread-Index: AQHVYXKtYveRbP8T+0C8nSsNeGeMcA==
Date: Mon, 2 Sep 2019 09:44:00 +0000
Deferred-Delivery: Mon, 2 Sep 2019 09:43:04 +0000
Message-ID: <MN2PR11MB3565DED578369DCA9B1BE4E4D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <14914.1566593238@dooku.sandelman.ca>
 <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com>
 <22118.1566866805@localhost>
 <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com>
In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cisco.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e15fc4de-6d53-43c9-a6bf-08d72f8a1622
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 09:44:01.8876 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ftJfjzg3EVF26yNz/OZN+bZJogf/sT7GLU6s4jkXmdsYkNDd6JzYNzNTlR6+b0X/AQtWPK+LDUTT5s5UmsCO/w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3663
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/EtHkWdhMbcbmRQP_ACcFT3e8J_8>
Subject: Re: [Roll] do capabilities need to understood, can they be added?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>,
 <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>,
 <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 09:44:08 -0000

Dear all:

Seems to me that sometimes the capability of the node is something that onl=
y the root cares about.=20
At least that's true when the root needs to know if all nodes support a cap=
ability. It wants to flood a query and gather the responses from all. Missi=
ng queries would mean a unicast retry I guess.

At other times it might be something that the parent cares about. In that c=
ase it asks one or all of its children.

So we're after a capability exchange flow that is unicast or multicast, wit=
h a unicast response. Either from parent to child or from root to any. The =
flow would be independent of the storing vs. non-storing MOP.
We do not really have a flow like that in RPL. It's akin to a software upda=
te, when the root wishes to now if all nodes have received the full image.

The DIO could be stretched to convey the ask to a group, but it's hard to m=
ake it reliable. The DAO even less OK since it carries destination not node=
 information. As of today the root does not really know if multiple address=
es are on a same node.

All in all it seems that we are after something that is needed by RPL but o=
n the side of the current protocol. I'm not too sure that we should overloa=
d the current messages for this. Rather, we may build new objects for Nodes=
 information and capability. Like a unicast or multicast NIS (Node Info Sol=
icitation) and a NAO (Node Advertisement Object). We'd design operations th=
at are independent of the current MOPs. Note that we could use local broadc=
ast NAO to discover siblings and siblings siblings, something P DAO needs a=
nyway.

Please see below

>     mcr> Are they individualized, or does every node in the LLN have to s=
upport
>     mcr> a capability before it can be used?
>=20
> Rahul Arvind Jadhav <rahul.jadhav@huawei.com> wrote:
>     rj> Nice point. I haven't thought about this in detail. In non-storin=
g
>     rj> MOP, it may not be required that all the nodes support capabiliti=
es
>     rj> but in storing MOP, every 6LR needs to add the cap (if present) o=
f
>     rj> the downstream child, thus requiring every node to support it. Th=
is
>     rj> definitely needs handling in the draft.  [Ref:
>     rj> https://github.com/roll-wg/MOPex-capabilities/issues/1
>=20
> I see:
>=20
> 1) the root announces a capability.  6LRs that understand it may use the
>    new capability unilaterally if they understand it, and see a need for =
it.
>    Nodes that do not understand the new capability are not affected.
>    This could be a control plane thing, or a data plane thing.
>=20
> [RJ] The problem may be in the other direction, .. In storing MOP, how sh=
ould
> a 6LR which does not understand capability treat a DAO containing capabil=
ity?
> Also how should a 6LR treat an unknown option in general?
> 6550 mentions how to treat unknown RPL code but there is no handling for
> unknown option in DIO/DAO. Is there? I searched and could not find.
> Most of the existing implementations just ignore what they don't understa=
nd.
>=20
> 2) the root announces support for capability that it wishes to enable, in
>    order for it be used, every node must support it.  If every DAO from
>    every node supports the capability, then the root announces that it
>    is turned on.
>    This in effect is a two-pass system, requiring either two capability
>    bits.
>    It might be that it is better to encode these two bits are three
>    values (plus 00-not supported).
>=20
> [RJ] Another scenario could be that Root announces support for an optiona=
l
> capability. The 6LN just needs to know whether it could make use of this
> capability of the root to do something. It may not need to reply back to =
the
> root saying I see it and I support it.
> Also should we be using two capability bits or we could use the info on
> whether the bit is set in DIO/DAO to infer the direction.
>=20
> 3) any 6LR may announce a capability to it's children that it received fr=
om
>    it's parent, if it understands that capability.  If it does not, then
>    it MUST clear the capability.
>=20
>    This can be a unilateral capability (like 1), or one that has to be
>    confirmed (like 2).  So this is really 3A and 3B.
> [RJ] I get 3A .. but do we really need 3B. I mean if the node also needs =
to
> indicate that it also supports the same capability to the root then it ca=
n set the
> same bit in the DAO and send it back ... Thus working in both directions.=
 It may
> not be required that capabilities be handshaked in both directions
> mandatorily. For e.g., root may indicate the capability that it has acces=
s to
> 6BBR and that unaware leaves could register through 6LRs. Thus 6LRs could
> proxy the NS (EARO) and other relevant messages. In this case, is it need=
ed
> that 6LR reply back to the root saying it supports unaware leaves?
> There might be another example which requires 6LRs/6LNs to indicate in th=
e
> reply that it supports the feature asked by root using the same cap bit i=
n DAO.
> The DIO/DAO decides the direction but the bit can be the same.
>=20
> 4) any 6LR may announce a capability to it's children, even if it did not
>    receive it from a parent.  The capability is not to be repeated by
>    the children (regardless of whether they understand it), unless they a=
lso
>    wish to enable it.
> [RJ] agree
>=20
> I therefore see several issues to resolve.
> For capabilities that a node understands, it can know which type of capab=
ility
> it is.  For a capability that is unknown, if the behaviour is other than =
"set to
> zero", then we need to tell the node what kind of capability it is, and h=
ow it is
> encoded.
>=20
> Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available=
, (3)-
> query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all zeros=
.  We
> could encode capabilities in three bits, so the behaviour would be part o=
f the
> encoded.
>=20

Would you encode capabilities in a bit array?
I'm interesting in signaling whether we can live without a capability or if=
 it the node must become leaf if it does not have it.

All the best

Pascal

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> =3D IPv6 IoT consulting =3D-
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll