Re: [Roll] capability handling

Rahul Jadhav <nyrahul@outlook.com> Tue, 12 May 2020 13:06 UTC

Return-Path: <nyrahul@outlook.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 57CE33A092A for <roll@ietfa.amsl.com>; Tue, 12 May 2020 06:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 F__SgdGMpRPu for <roll@ietfa.amsl.com>; Tue, 12 May 2020 06:06:41 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253079.outbound.protection.outlook.com [40.92.253.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9583A0407 for <roll@ietf.org>; Tue, 12 May 2020 06:06:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jaeJ1vJmwcL1AcSP4RNtAjr63ngsmogWo8RThnIGcVAHDOyFUtuEeYM5bE5U9llu2h8Hdr7XUGHkptxlEn3SjMjNxz3AC3ixhKyz4Zhkgf+ZGkEbzgINiUpnID7cv25x9Sn4+6KqWzvwAxHFnEcC6PM9mGwLObI5Yksia+2zQEPigdCVpSBYy+OCz9z1lx9R8hXwMRAjhK3+Z49aR+qxh3duW+8j1Wt2AWvAFE3TI68fz8fwCC6RU26j0UGRDv2cQnOmM//krtji3k/l3ATYy4vqdqQq+vTTV+myl1TDCb4mRZhuZxy7/0Z8ixZwZgUPMwQNpizHlD/QJzDIL0KLuw==
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=HRJDOvSuTy6wN3PlTOcjT41dXlil2Rz/1gdZL30eh44=; b=CMxKQgdDz0mwcfzpWdQeEdUGtHB4X+5NutXejmMhvF2Qsk9aCZxpFK6x4QK2qPOyc2JoO+uGoDVhebd4gSNt0yXR260SGHhCGw+sHfAnakdAKMs208CDDvPsCyV6tKlJmh+OkrypKF+vC7uK5VKeqrTi+4BQragsNXpV7FNfIINNOv40s8xftZXuAIcn4eCWMXHPKEqzXcz419UiHbH7R1yci3TboUCkeOCVC5j/CYaQ6+Qk+bvYlC6fCwZRVNijpCiGSrzcDVcRjJ5fXZgR5wWWOpFL2LNoz1ZWFsEH+6c+1iRK2aU4e1FpTWswitPGZmGDrX4GO8Q+Nn2LEDUjEw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HRJDOvSuTy6wN3PlTOcjT41dXlil2Rz/1gdZL30eh44=; b=U9O3sW66ibJ30tQEax2Le/xIim5wFOc+rYgsbU1H+wlgffDwZ06/vkVGHjNtPjOxbjiQlU6+Qrtsg+KPCgR37mTaJJ7QeiGPLTQDYZg34PNTIoFUOJPo9NUpAtquu7Ix755xxWcvftZtiXZlhCVk0neubbwRGeSYpTujIZz0PNaJ3mnqBwGqd4Zgv4Rp5vEKQusGnOlTqv6IEtIPJWqPDUXqeDAIiv5XIjgWxNNiYsgzT6fcMd+8dPeGvF2119K5tcuMtxRoLuFU3hlOEwOrImUiURjTk7Sn30coO0Cp+B0Vw5AP7UPegFZqOHiYKqvW0R6JDOFjb6OAcMMb8tRFPg==
Received: from PU1APC01FT046.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::43) by PU1APC01HT069.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::303) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Tue, 12 May 2020 13:06:37 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.56) by PU1APC01FT046.mail.protection.outlook.com (10.152.253.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Tue, 12 May 2020 13:06:37 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::6174:ad1b:55:41be%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 13:06:37 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: capability handling
Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMegAacV3CAAK+i/oAAxnYQgAAEXc4=
Date: Tue, 12 May 2020 13:06:37 +0000
Message-ID: <BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0@BM1PR01MB4020.INDPRD01.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>, <MN2PR11MB35655600585A20BB9F802BF9D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35655600585A20BB9F802BF9D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-IN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:651BE267418B0E62608D73FF3E57915D86246B38A1D5FC89BFC34A2B55B7ED36; UpperCasedChecksum:5ED60CD4A5177962D4E63B050AE8E02EB79B5EBF077CC819350FD5F35E1BA5B2; SizeAsReceived:7192; Count:44
x-tmn: [DuCAj++gGaWsWqD9vQIHzNWftjdSmFwZ]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 50212c67-dafd-48c8-bed1-08d7f6754dad
x-ms-traffictypediagnostic: PU1APC01HT069:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HVBhwA04INBn2a3VFNYeBu45Mv6gvJmD2PwEicLHhvuTZaZkc6rMOwscm8Zus1qKpbyfTW1Wu2yH0Jrql+vTtDXrkNB4G80QOAzxgNHuWnbPfKxJi52meiImxEcJq8QvrKiwa1EIMG4BBkY/Jb5VEiUP8siK0aweFiCmn71YesgkONBRxejW2wts/OFqVs4lE0BHF+G18FhvpCQNjskxrA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: PODKPKVFFIq+CIeiaj/iY461LmCzi01YrqlS0r9zQ11zbg2GgOzMDS96/rYP3ODJI5tuoNpbjbtJqc5jgfPRI5/IMfNktdQh9SDLT46KrhESREi8QsuOtnSjyS5yjLVjMjsUNkT/iSsaVHTTR5CTTg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB402073B08B9B7A6121A7D8EAA9BE0BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 50212c67-dafd-48c8-bed1-08d7f6754dad
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 13:06:37.0263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT069
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7Y_r4S5IOGSF4h_eWf8LpCZnz4Q>
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 13:06:45 -0000

> 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.


[RJ] Sure, we can provision this. I agree that extending this later will be a pain because of compatibility issues. Anyways the packet cost is just one bit.





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: