Re: [Roll] capability handling

Rahul Jadhav <nyrahul@outlook.com> Thu, 07 May 2020 09:36 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 75A9C3A0AEB for <roll@ietfa.amsl.com>; Thu, 7 May 2020 02:36:50 -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 KK65-VmQoXEk for <roll@ietfa.amsl.com>; Thu, 7 May 2020 02:36:48 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255100.outbound.protection.outlook.com [40.92.255.100]) (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 61CE93A0AEA for <roll@ietf.org>; Thu, 7 May 2020 02:36:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/f/2UEaouEYD7oF9vrE/O33pLXj42H9ZZ91egz2ghjG/J5Ddsq+cCQR6GLxdZOTc61ziBPM9fLFWqJGOA+rZXs5sJov/wvQjFg2Ny/wAa+356yAKdDcp0CjjA87uXrFTfgcRHftKi5a6nHgftr/YIrV/3m50GeOFOoQaREZ+Z2PjjKGUBYxmGDwETGme32iagPZO4G6GwE1B7C5cIb7TKpmxqym5t8lJ0Gg4vFuy5NEiOdbFwRnqQmiK6mo7JipYkWTOvvqZzRZwA1Eg1W5ztdcu/4I6TMxHw09i368f0Wq2KDh18CBYQzTPSkoQ/zupwiwRVVqjB+/DS/u0aIoDA==
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=GfGDCn3o5q2McdzoILa+5JhCJIN+u4rSBJxen3oqYH4=; b=HZGt+2UVIVIWvOizdNMHgmpM1H3zm8Q9OB19T5q+kIjrpAR14VKTiRONbMt2J8m7SmrX/2j4dhz64w2ypoQILyaO1gr7y1S7vdB1gUuCWyiFttBQH7bc0Z0L/9KeajWMBfCums7kvmlLAvpdAWRoG9OSJ8hjZPUL5rnLtdFA9OrqAx7DNnd6fGY2PLBAjjf7QWFNQzw7fr8DiLLhNmqQWUcTt7zIzy1krk/VevxfCIDcncFujNr0EIfTcsEVlCSZj175OpSeG61lSGY7z+cC5svhat1vFzNVAvWuRRX1S3q8ylBaFgizPGbfw0YZkg57BKDTjMdctU0lGWrJOoDesg==
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=GfGDCn3o5q2McdzoILa+5JhCJIN+u4rSBJxen3oqYH4=; b=eSYkqEg9QAQW8uLB5PApwRiYVXjPtcPbit/z8rmAixrzKBUFKCQWgv0q0ec5ms3waxjmv+axvzf2o0SG597ymKdYiOE+NjOpAFrKL3dznlZZPwFmawTV6rYlXmh0AVJTp8kuWu9Du3MjtjKrSY4L+VROL3mvhdgDWBjtUUH5NgAF48ybP2VuozCbX5ZB7JEUtYJedyAtGO9vpeD5m04Ym2cqZG3E3uCEmaXxrRzklAUpNKSH6xQgBzNnRwIWBnrhbdCWQ9Zj1YsiMnY96xficjLQqoHX5Dh5JagXOPLdcVrMeJi9LiD9MdrDC6aHoT7P8ykQDUvn9FTsXGtdGCRfuw==
Received: from HK2APC01FT033.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::53) by HK2APC01HT069.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::481) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Thu, 7 May 2020 09:36:44 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.248.59) by HK2APC01FT033.mail.protection.outlook.com (10.152.248.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Thu, 7 May 2020 09:36:44 +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.2958.034; Thu, 7 May 2020 09:36:43 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: capability handling
Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKicWyMe
Date: Thu, 7 May 2020 09:36:43 +0000
Message-ID: <BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <BM1PR01MB402011EE18D8BE1C70A15AE4A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB402011EE18D8BE1C70A15AE4A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-IN, en-US
Content-Language: en-IN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:378E9C0143B31C1653968868EE70699B5340158F2456581EEF35BF39B7C8951D; UpperCasedChecksum:A15C3FEFB8C103E7823D715F00561CA19D4406B27D54C3C3F973FA2837E7876F; SizeAsReceived:6832; Count:44
x-tmn: [suwjgCYPvY2gGkcDm/sprn8P1OLdW2dp]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 637e49a5-b180-4619-133c-08d7f26a277b
x-ms-traffictypediagnostic: HK2APC01HT069:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6CPMCI4vfDQV2vxp2QAaIRyOAp8m21W3aQRn2uwzvXnJxAIOS/MejS7l14uywgd2zsuPMhEMdGiM35lmRkMzP4xyWfwhrl/21BZLL4vzOSuCprTbBOnS2h1wTqTJLZgab2MBsRg3xZImXc+IidE2XaitQgmW+HumBdJOz2dey1HnayDzha9FwQ4mK4GUBS9bk50bWQEqJzEYq1B4xwhXBQ==
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: EJbhnNPW7Ts1tRkvqOzl3/jAmjLAQ77/pYqLHO8fTkur6ZTuRpnivTdDVNeJ2WJs6kJ67IFFWvlE+vhPH1gC7/mEeQXB5lawpsRR8Y+nzfO4n/EzyqM6xjTLn/Igd7+UxXup3lshG4tG+QFZ4+fj0g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020A5A77C7B4C9C16AA0598A9A50BM1PR01MB4020INDP_"
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: 637e49a5-b180-4619-133c-08d7f26a277b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:36:43.8217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT069
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7BGjkfxwLeMSmpGfLgSXlF3a3IE>
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: Thu, 07 May 2020 09:36:51 -0000

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