Re: [Roll] capability handling

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 12 May 2020 12:54 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 2FCEA3A08B9 for <roll@ietfa.amsl.com>; Tue, 12 May 2020 05:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=b6XbXBiW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T0QYozV4
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 jlCrKllQ6lNO for <roll@ietfa.amsl.com>; Tue, 12 May 2020 05:54:15 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6231F3A0899 for <roll@ietf.org>; Tue, 12 May 2020 05:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22308; q=dns/txt; s=iport; t=1589288055; x=1590497655; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3ujA8WSJFUT+MpcC8pJwEkk87+F/4RaaNHbsptEv0jo=; b=b6XbXBiW7xJxBhiBia2RV+Ns4ajggZC4+s7gbb4B7ppkxIhO+LGHWUL/ K690MMQ6V2pzFg3xDRKnfohAdxbLyAlw/shORWd+JLt8/SHo67tWflNFu 8BdCjQcMNa0LV2RlmPLv0XbcXlRISpNXbA2SDK52Txq2vk9hCPlzvFVTf w=;
IronPort-PHdr: 9a23:U67LlBFOphDgtzs3H10Qs51GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DiDwDGm7pe/4MNJK1mHgEBCxIMQIJsAS5RBW9YLywKh2ADizKCEZg3glIDVAsBAQEMAQEtAgQBAYREAoIFJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQIBEhsTAQE4BAsCAQgRBAEBIQcHMhQJCAIEEwgagwWBfk0DDiABA6RPAoE5iGF0gTSDAQEBBYU3GIIOCYE4gmOCSYcYGoFBP4FUgk0+gmcEgUEBAQIgNIMRgi2ORokqmn8KgkqYRYJciGeRd45RnnYCBAIEBQIOAQEFgWkigVZwFYMkUBgNkECDcopWdDcCBggBAQMJfIx3AYEPAQE
X-IronPort-AV: E=Sophos;i="5.73,383,1583193600"; d="scan'208,217";a="769420576"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2020 12:54:14 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04CCsE5A010893 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 12 May 2020 12:54:14 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 07:54:14 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 07:54:13 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 12 May 2020 08:54:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xlbh8WSdlql5gZfteC8QHFXCRsvDXAPy21aQzCg47RwPAo/Cf22XgCHndIIPiLjBA8Qp6JkaX98cbeGJcfNRcgCwphFSpMNYpX0I9MZaHrnE/qZuC8+JNa8dkiHYpPaliXLVFcY5EN/1XQ4Jcj6Ig4/uBzTtSePTZAj84dRe2/2GFBl18P8ijveufREpO/g5hmeW/MFm0tb1/TDVzUw0x8ABaPkR5FUKjk6pt/aE6ROPzJGf2hx8605dckQR3hlGTYrbH1hhWvZJkzxIsWof2zhVefOHBqKoZ/xjdG/DmQ54+/n5enM5ZT7NXx/fs7Om6yb2Xx/HFG7XBuAg/7nrUg==
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=c2ul1Nk3Tz9/lng6TQXv/Zt6uRO+LuLqoxAJq7dG4GI=; b=HtsjbB56QH1QNwwgbXtwF/QDylLzXw+04x4WlmRNk0y4jQtFYH+XXub2HQ50sy4LE1okrD7nru6Mh0J8yLvrhpXjGPlFoXg3B+HsEwp9rqotxkOx2q9kFYfsOh/tMKnrYNUvTrHMVFMW7cs4h3gdn838fqRgHPrNVsZdfMeEF8mosizsXHkjcpV1uUOE28m6qehHx2lIYAmp23ACET+GkNEObZ+g/m5s9lU8XHb5dXQw29+PO9RL4tb0gQmYs4tYCgF1s97hJ7TnO7vcF/2vLdDVfAFhRuT31uYBAlV3Ts5cWW/WQ1ODkMhGhfBE5m6hwVqincaDY0go4Qyyzqhivw==
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=c2ul1Nk3Tz9/lng6TQXv/Zt6uRO+LuLqoxAJq7dG4GI=; b=T0QYozV4phbi0B5YZRLMxRgJLbKqVsbsJ46CpbiTE0sJxM9/I1X8FhDAxd1svFOkfbRwDEnUh+V6nuGKNXBoMkg5CqbqYWClXFt7tCgX8m1GvI1G4Yu4jUeCHnOXwrop2ZXN4l+CVwPV0yVz/qdqQ2YGpSVF+ifMIVQNgiVtMLI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4519.namprd11.prod.outlook.com (2603:10b6:208:26c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Tue, 12 May 2020 12:54:11 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 12:54:11 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: capability handling
Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3CAAK+i/oAAxnYQ
Date: Tue, 12 May 2020 12:54:10 +0000
Deferred-Delivery: Tue, 12 May 2020 12:53:37 +0000
Message-ID: <MN2PR11MB35655600585A20BB9F802BF9D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <BM1PR01MB402011EE18D8BE1C70A15AE4A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM> <BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB3565DEA642FD973CD5A52E4ED8A10@MN2PR11MB3565.namprd11.prod.outlook.com> <BM1PR01MB402072594AE73E644D725459A9BE0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB402072594AE73E644D725459A9BE0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [90.116.245.181]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8be0fc61-c06f-4033-072c-08d7f673912a
x-ms-traffictypediagnostic: MN2PR11MB4519:
x-microsoft-antispam-prvs: <MN2PR11MB4519869336D3648A4F3C30BED8BE0@MN2PR11MB4519.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LbbW/B4ArBv615bnliwK3gPNL6zBBATiIwBGLSh/U9CXT+rk8tKSQiA8qD67FVOZRVHndpK6RMWfRNCAHU0BdnX1Zpy+OY+I96ogTk8m5B0ByzDuNrBgd9NyS3FFp+yUhmaXuHmycNxWe6ENsQ8X8HeEUMRDJYbxxs5N0/Vf05drE3laozHrRPxkfoR43Hw7SihTjLQCGyUKU3FAaG67LSZKdKGG/IigAyzppZSx5T+FnnSD0+RSFmomPxOwV3U/M/bog1qsQrPVfA+CRyPI+7T9Qdd6JOV7VAxHZnAUAaZyWW82KfsJpz3P4t/YnRfxcaJdJGjRqipR/swIhGZ0Qlso72xCuJL5SWkwnISF+5DDz33EwVMCd+ZAccuVrq3cOxMh0bs8x4sEBgvq64QTa0tCm6h7edcOiaiVE3vtX2Stcl9zDSba9d3xMXXSIhyDOPCtyEVYqLIzd4GWAdFFgQ/CbqtVfdt668ykAF7ODWHZ0cTXdpH95HM9DfZLxPKYrakfa45iJ8ohjrfGHd9t0w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(33430700001)(7116003)(5660300002)(55016002)(33440700001)(9686003)(316002)(7696005)(53546011)(6506007)(26005)(186003)(6916009)(71200400001)(8676002)(52536014)(76116006)(2906002)(8936002)(66476007)(64756008)(66574014)(3480700007)(66446008)(66946007)(33656002)(478600001)(86362001)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: i08W/8ZsaoyVsyPFyYjfY6N7tvURbOab2uhFV4FjsftzYHKCUuxg0F//8WeDzQgiX+Vqgh6orbDKUruTdxfUh4jZ7m463GYmiHzulMR79XPpzvbYG92DYrw9aUc9DCWHsRmHUHHleMWJ8C0Kphk8dKvnaRcrmyMxKvo1s/bhnSSq2cIVYsZ91ah5QrtdTkgq3gQOm4y7TIp6rGlz/abLG5KjHQaj7puwbeUzNHtcLvpkHFku/ekILKHs/2sdsyeYSl/oFLHZLsg9btTpuWpfd9JQnaUZcVPFGQfx426ghC12XWdrmVPicJiDyxWdUg+mH8xkG2gZ/xqNNDeqO+txnvkv90Awupr9KIcEYY1TgTH2rTfpVDY8DQB+mnB7U8gLdJqUP3SuxSjuy1vXzM9MM10AUsHEcv25q/fZ7UXg3WGXyrQWk4WvP+Ohq0Q7o/hDGb5hy8pwcP/ZesZMHgNWp7gKBpGc2/I81M1KAap2gPKzruKMzkmI26VXOuh21siL
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35655600585A20BB9F802BF9D8BE0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8be0fc61-c06f-4033-072c-08d7f673912a
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 12:54:11.2887 (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: NUG5zd4YzyegZsyrT+JPQ2762TB5eiGWFIiJy+1pEIHecQCuFlR5fvW3hfU8RGCIELVmFyEbNh1xd7Gdt6Xb1Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4519
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/weEc48zNMD2gyEeoPTBClZje0Pc>
Subject: Re: [Roll] capability handling
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: Tue, 12 May 2020 12:54:18 -0000

Hello Rahul


> Regarding the critical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, there should be a way for a node to drop the message if it does not understand it and still be part of the network as a 6LR?

I do not have an example but say a DIO requires something that a node does not understand, and that prevents operation even as a leaf, then we need that bit. The problem is that we need to design the infra now - before it is needed - so we need to cover all cases.

Take care,

Pascal

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: mardi 12 mai 2020 03:09
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capability handling

Thanks Pascal for the feedback. Please find [RJ] inline below.

________________________________
From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco..com@dmarc.ietf.org<mailto:pthubert=40cisco..com@dmarc.ietf.org>>
Sent: 11 May 2020 10:38 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] capability handling


Hello Rahul



Sorry for being late on this:



There are different things we may want to convey:

- local/global: indicates whether to forward the bit. Local is a parent property, Global is a DODAG property. It boils down to your "copy" action so to your point we do not need both the G and the copy bits. Note that RPL also uses the term "propagate", and I tend to prefer using it again here rather than copy.



[RJ] So it seems we are aligned. I will remove the 'G' flag in the next rev. Also will change the term to propagate (aligning with 6550).



Then there's the things we define for the configuration which may also apply to capabilities:

- critical/elective: indicates what to do when the capability is not known; Ignore this capability vs. drop the message

- router/leaf: I'm wondering if we have a case where the node should become a leaf if there's a capability it does not understand. That would be another bit.



[RJ] We already have provisions for router/leaf. 'J' (join as "leaf only" if cap not understood) and 'C' (copy) flag handle this. Regarding the critical/elective bit, I guess we do not have a way for a node to drop a message. So you are saying, there should be a way for a node to drop the message if it does not understand it and still be part of the network as a 6LR?



Does that help?



[RJ] Thanks, it does help greatly.







From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: jeudi 7 mai 2020 11:37
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] capability handling



<< sorry my last mail was sent incomplete>>



Hello All,

We would like to solicit some feedback about two points in context to capabilities:

1. Capability Instances: Currently the document instantiates two capabilities viz,
        a) Capability Indicators (which can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability which indicates total RIB capacity the node has. This should be useful for DAO Projection.
        Do you think we should add Neighbor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis:

       Do we need an explicit 'G' flag? We already have a flag (C-copy) which indicates that nodes have to copy the cap if they don't understand the cap. A global capability from the root can be advertised with this bit set. Nodes understanding this cap will anyways know how to handle and nodes not understanding it will copy it based on the 'C' flag. Thus not requiring another 'G' flag.



Best,

Rahul

________________________________

From: Rahul Jadhav
Sent: 07 May 2020 05:28 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: capability handling



Hello All,

We would like to solicit some feedback about two points in context to capabilities:

1. Capability Instances: Currently the document instantiates two capabilities viz,
        a) Capability Indicators (which can be used to carry flags such as support of 6LoRH)
        b) Routing Resource capability which indicates total RIB capacity the node has. This should be useful for DAO Projection.
        Do you think we should add Neighbor Cache capacity indication as well and what would be the use-case?

2. Regarding the use of 'G' (global) flag on per capability basis: