Re: [Roll] do capabilities need to understood, can they be added?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 02 September 2019 15:56 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E8D120048 for <roll@ietfa.amsl.com>; Mon, 2 Sep 2019 08:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Ytf3D6uS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wvzyLY/Q
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY_6Q2Jbbfvc for <roll@ietfa.amsl.com>; Mon, 2 Sep 2019 08:56:06 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1160912082B for <roll@ietf.org>; Mon, 2 Sep 2019 08:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7691; q=dns/txt; s=iport; t=1567439765; x=1568649365; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AJ9cS7RQ2GW+drL/M6qkG8d00nzN9chuK+TZKCyHhUs=; b=Ytf3D6uS6jRrGkwR28zvqmcUMu1wq/asM7jEuPwwaJEdDS73dE8tnyC2 DJudRT5fmGuoKat7KM6EBipj/9DvEfUG6+mYgzCAVN7nAvrLnqODxD+d0 OXG77uIM/ZWlwF1AHchHcXkgR7DvkNIYdOMM455wJTJBPdfkoj97NiXw7 Q=;
IronPort-PHdr: 9a23:Rw5iAxA9WB9QcDYqfGohUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DLAABoOm1d/5FdJa1lHAEBAQQBAQcEAQGBVQUBAQsBgURQA21WIAQLKodoA4p1TYIPl2yBLhSBEANUCQEBAQwBARgLCgIBAYFLgnQCgmwjNgcOAgMIAQEEAQEBAgEGBG2FLgyFSgEBAQQBARAoBgEBJQcMCwQCAQgRBAEBAR4QJwsdCAIEEwgagwGBagMdAQIMnksCgTiIYYIlgnwBAQWFFxiCFgMGgTQBhiiBWoN1GIFAP4EQAUaBTlAuPoJhAQECAYEmHAgWJIMXgiaMTDOQGo8ECoIfhnOFCYh6gggrhzaKWoQjjy2GPpBUAgQCBAUCDgEBBYFXBC2BWHAVO4JsgkIMF4NPhRSFP3MBgSiMDgEEIYIuAQE
X-IronPort-AV: E=Sophos;i="5.64,459,1559520000"; d="scan'208";a="624028710"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Sep 2019 15:56:04 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x82Fu46O028622 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 2 Sep 2019 15:56:04 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Sep 2019 10:56:04 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Sep 2019 11:56:03 -0400
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Sep 2019 10:56:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HKyjKc22tKY1TxQCeEDuCc1yOyptI2rWUDzTLN/i7M/cojS31RJBudIHnSJ61KyBL9eCGgaGHC18YOBB4hQHysI/8gCMnouCyQ+grukt2Bj2q/+kJks6fBk/PtfsTm7c+ntKapotq8+77F1X7z0omwNz8/SjwAcoinLiB/pqDYqESTG+a/C+L9Hw227spEA2wsyMkNej/SR6DklJhzZUq7tmOai2J65AyHk6A7XZrTKD/UVOMIfAanw4kWofGgyP2xZuP2jKgkiz1FecbY+vMIfnukG7aY6+QKDSHST5LKYQ/CRULXplfYTOvf1Z1vxp64xRnSq0/zOL3qN+n7qWYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PkSYvlS6Dm7068XaxhU4WGvaFbxvAB4bTMzh3URI2rE=; b=MbxF0TEd1asN5ttnCcQmOn+3Q58VqqdtPfPX+bTHxJyo4IpwuECSba09lK0jR1ZDYeL0MdRtfaT7hvJv7FVGiNJQUPOygsCILpUvVaOYAAQIX1s8zxgp9F388BEhwjbeMcsjWbqnLHy5o0Nu8RE7HGvemR/Pne27ltOwRh6c6ESNHUT/yCpuyb4A2lBQIONvP2FQjgLb4I+nVzLe/D5igTfGFo9lqFRKVg/tzKYUhoEFcEVdpvrU5Jzwsl6CmbnKR5pNw1OTolVhJ6EOxqOX1+qfymkWyXhNifARu/uYot+AK7qIe59wM/2ICXK6c5Fbx93D/kArRBRKOOxcpfcIbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PkSYvlS6Dm7068XaxhU4WGvaFbxvAB4bTMzh3URI2rE=; b=wvzyLY/Q4IOAsAN89auv/pAEuxqQy/Rh/1kQUFKTDwKy5J5thhFkH1UDYXX52lPI+t9F40M+uT5LHB6oSxrlF1OyswbdIrhkaIELvxrAV3wv5/YN9mcQyhaMXh6r/fLlCwqeAjctJBSxaYY6qIPetWmOOicKFzcYWEN5m6WZLCo=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4207.namprd11.prod.outlook.com (52.135.37.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Mon, 2 Sep 2019 15:56:02 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.022; Mon, 2 Sep 2019 15:56:02 +0000
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+0C8nSsNeGeMcKcYhbNQ
Date: Mon, 02 Sep 2019 15:55:59 +0000
Deferred-Delivery: Mon, 2 Sep 2019 15:55:12 +0000
Message-ID: <MN2PR11MB356586AD1BAF9B31CBC53648D8BE0@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> <MN2PR11MB3565DED578369DCA9B1BE4E4D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565DED578369DCA9B1BE4E4D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1004::294]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 96f1abf3-5c71-4cc3-25dc-08d72fbe0df2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4207;
x-ms-traffictypediagnostic: MN2PR11MB4207:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MN2PR11MB42077180BD19B9AA437377D5D8BE0@MN2PR11MB4207.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(199004)(189003)(13464003)(14444005)(86362001)(6116002)(6436002)(81166006)(81156014)(486006)(8676002)(6916009)(9686003)(6246003)(14454004)(305945005)(46003)(53936002)(33656002)(446003)(6306002)(55016002)(66946007)(8936002)(5660300002)(74316002)(2940100002)(966005)(316002)(7696005)(2906002)(102836004)(186003)(52536014)(478600001)(11346002)(476003)(229853002)(53546011)(6506007)(6666004)(25786009)(71200400001)(71190400001)(256004)(76176011)(66556008)(64756008)(66476007)(7736002)(99286004)(66446008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4207; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4/giY/4fi8qw7nko4shNKWrSKVQ2YtY+Au7s1T99xl8eToTnEeDx9iRk40rX9l3T8dHAFXP0PI6oZRta63O5whxI7frCi2gfLnxDIZJl56tOqAHNEJDxQXbRIet2WSq0BnEGEGFnSqDzO2fmrCKVpYRA77YLKrXAfk0pKkVRRJHUxPZlw967KEqFl/DzmW0gWTbNL6EM4GLxKd2t0FPMBRrz+HPZG/wZeN11ho/aPbXU57fyoLv8hYXFDDMv4ocHPTGbAxG+08oag9PXXrbHu7QBTdIvaCRfWzBgv9UaQVGI+rIdJRuMtg6WzMrHrsz/SLuCDCwBUzONeSzrtbmZqUgvzNaLDJ2334NQwKbNA1ZsX8GfdR1ZNeg5tiRRI1e+wu5Ftyop5MAFcpSfzn00BVDI4o3KR7GMWe9+EcJuqP4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 96f1abf3-5c71-4cc3-25dc-08d72fbe0df2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 15:56:01.9070 (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: fS65AyZylYZirkN0aCPSYoEk/v3tUaIjE9REu+TcH3yb0D3UFm5TzOTTVqG3lxts/BWsxxagjr8O6jJ117kRKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4207
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/56b3DvaJc0DF8ASym5RhL4G6Ppw>
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 15:56:09 -0000

In addition to the below I took a refresh look at RFC 6551. 

https://tools.ietf.org/html/rfc6551#section-3.1 provides a shell for capabilities such as those that we are after.
And
https://tools.ietf.org/html/rfc6551#section-3.2 discusses how to handle a resource that varies over time and is subject to consumption and exhaustion. Storage of routes for P-DAO has similarities with that.

All in all I'm thinking that we could extend Node Metric/Constraint Objects and how they are used for DODAG formation. We could for instance use the metric container as defined for DIO and create at least one new message to report to the asker for the reasons below. 

Thoughts?

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: lundi 2 septembre 2019 11:44
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: RE: [Roll] do capabilities need to understood, can they be added?
> 
> Dear all:
> 
> Seems to me that sometimes the capability of the node is something that only
> the root cares about.
> At least that's true when the root needs to know if all nodes support a
> capability. It wants to flood a query and gather the responses from all. Missing
> queries would mean a unicast retry I guess.
> 
> At other times it might be something that the parent cares about. In that case
> it asks one or all of its children.
> 
> So we're after a capability exchange flow that is unicast or multicast, with 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 update,
> 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 make
> 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 addresses
> are on a same node.
> 
> All in all it seems that we are after something that is needed by RPL but on the
> side of the current protocol. I'm not too sure that we should overload the
> current messages for this. Rather, we may build new objects for Nodes
> information and capability. Like a unicast or multicast NIS (Node Info
> Solicitation) and a NAO (Node Advertisement Object). We'd design operations
> that are independent of the current MOPs. Note that we could use local
> broadcast NAO to discover siblings and siblings siblings, something P DAO
> needs anyway.
> 
> Please see below
> 
> >     mcr> Are they individualized, or does every node in the LLN have to
> support
> >     mcr> a capability before it can be used?
> >
> > Rahul Arvind Jadhav <rahul.jadhav@huawei.com> wrote:
> >     rj> Nice point. I haven't thought about this in detail. In non-storing
> >     rj> MOP, it may not be required that all the nodes support capabilities
> >     rj> but in storing MOP, every 6LR needs to add the cap (if present) of
> >     rj> the downstream child, thus requiring every node to support it. This
> >     rj> definitely needs handling in the draft.  [Ref:
> >     rj> https://github.com/roll-wg/MOPex-capabilities/issues/1
> >
> > I see:
> >
> > 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.
> >
> > [RJ] The problem may be in the other direction, .. In storing MOP, how
> > should a 6LR which does not understand capability treat a DAO containing
> capability?
> > 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
> understand.
> >
> > 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).
> >
> > [RJ] Another scenario could be that Root announces support for an
> > optional 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.
> >
> > 3) any 6LR may announce a capability to it's children that it received from
> >    it's parent, if it understands that capability.  If it does not, then
> >    it MUST clear the capability.
> >
> >    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 can 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 access 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 needed that 6LR reply
> back to the root saying it supports unaware leaves?
> > There might be another example which requires 6LRs/6LNs to indicate in
> > the reply that it supports the feature asked by root using the same cap bit in
> DAO.
> > The DIO/DAO decides the direction but the bit can be the same.
> >
> > 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 also
> >    wish to enable it.
> > [RJ] agree
> >
> > I therefore see several issues to resolve.
> > For capabilities that a node understands, it can know which type of
> > capability 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 how it is encoded.
> >
> > 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 of the encoded.
> >
> 
> 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
> > - = IPv6 IoT consulting =-
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll