Re: [Roll] capability handling

Rahul Jadhav <nyrahul@outlook.com> Fri, 08 May 2020 12:53 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 309EC3A046D for <roll@ietfa.amsl.com>; Fri, 8 May 2020 05:53:02 -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 lBg7B-9mnNp7 for <roll@ietfa.amsl.com>; Fri, 8 May 2020 05:52:56 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253058.outbound.protection.outlook.com [40.92.253.58]) (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 CE9413A041E for <roll@ietf.org>; Fri, 8 May 2020 05:52:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XR2RWtvGO59Mbk5JhxDRF7hUoVD/DkMvJB6SfmvCy/X6bZZZ+0ktn/NRzkOmVOWHCo0pkz7ZrVfaymjmkdNDjqjI8Dq33iy4ROawsIPQ0eSLcVO/qSZfVEzZgbSHjwMXnygyU1WFe561svf4twdqDquAHn3ZwvPrJswbkhzjnh/33sl4GU+YvO4FjL3rw9AgDSX5HEwvbhIOmTN+NKd5pDrcvjZl4ZaG1h/qEhGn4sFxo5uCyFVEJHuclgtvN2IhWm/er0i4rXZAMfxSwTa6fWHAnDe25U1kQfFNt6d5J+xvaVWD970oXpQWzXKveK3AFRX1wtBNo61734fN6tkAJQ==
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=4pPqfVVpCm4LY2MMWLDKawEk5TMh2v4GFwlQsofe2dA=; b=ENmZISO3TzO82evzm2ea+dGUP8xIOkh1pcGhJ4Or38WsXxyLMFAVhhq1UVS3ZLpl8YH1vfKTK2Rx0rOtwn1bd+WbSPZShtPYZvFXyaYTffX4uJEpmXS18EyrLEcnImkiY/8yYitJ6dKnA0vOFyk7CCp5MvMLKsSHUeA5UsfS0nSxcrvQMhAeF+Im9hdwNleCDrvsxuZ7bx1GaPy/qDM1OV57EZPd2hccio1S+lZCHGUXdBOz+HGZzzv7U9nTWEMYHxdYFOoXgUVnHKpaOle6rTCsujso4dY/yZoUGvke2PucWdW8tW4byGcvR1bt306p8ihV0xmLzF12kyLaO4dL+A==
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=4pPqfVVpCm4LY2MMWLDKawEk5TMh2v4GFwlQsofe2dA=; b=OGZqlwUQmfMakRQj6hWW2gumByqK6kOAgfIqTqsDwzh5JLT/OFVBySicE3kaaNwqiXRxSgBLmSRaeqzWCRDDRINY57q0qiISbwe77mWxD6ADe89FIgGNw+SlUqR5c6blYtXPfc+oRKx2L8PW8TI1MXutoZANGAodCNGHpj6BOVGF9B8dckRNsanRcsCO2GfZ5Ancrd93GLSJ7eC+JOKyFdzWhvx9R8VvXnot0eDdN5f7+p2iN9eX3X32+iTGQOyfgFb8elAiQl+/A5Klo7rZln6tlUVkdJHYEFOSQIQ4C5pDFFDEi7Bq5Ue3rki9mh65NflXDEcgSB7oHpNHOGLTNQ==
Received: from PU1APC01FT035.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::45) by PU1APC01HT029.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::399) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27; Fri, 8 May 2020 12:52:53 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT035.mail.protection.outlook.com (10.152.252.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Fri, 8 May 2020 12:52:52 +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; Fri, 8 May 2020 12:52:52 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] capability handling
Thread-Index: AQHWJFAsZwgiM3y4ZEmUmGVmctTxoKic6mMAgAE5Y88=
Date: Fri, 8 May 2020 12:52:52 +0000
Message-ID: <BM1PR01MB40200BA596F107A09BD89DC6A9A20@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <BM1PR01MB402011EE18D8BE1C70A15AE4A9A50@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <31727.1588874478@localhost>
In-Reply-To: <31727.1588874478@localhost>
Accept-Language: en-IN, en-US
Content-Language: en-IN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:81C52B0D249977066F928021C18394A22D4C075D4FFA577943417B915F4818D0; UpperCasedChecksum:0127D78A619059A78E890C3AC5F613BC9253373E6FB046818DBA06AF04D218F9; SizeAsReceived:6828; Count:44
x-tmn: [poy+/NaZM2UZKKeasaqXZ1RKUeorjaBE]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 6d6af4fd-f198-4afb-33dd-08d7f34eb8b8
x-ms-traffictypediagnostic: PU1APC01HT029:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: oBX21UeQpG7SdJzYdFX3uG3W2S/+oCUEsINTTv9itQaaDUWeS2V1NgXA08JmHU4dCUpcuZFI6SPageawcSs/SgVEOk6IFCzNlRlfmb6K51Wp1g4ow7isfI2oIgK18/riJBCIdkuWC8rUo/v/62ZHvjrSB1oWndwDdf7x/7mVrrBf1kXF3rtqSw5SpFFxAZjuu6nkcYPsLIY5mOjYxMt6lIuAH8WQ/C+KXV9OzNxentJ9zY6ODiDVxXBpmnWWwBLv
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: 6z45W2t6A55JWs9AOIX17plAeJzAorGrqx1o7OO2DSwKWa1cDphyFI0AGM2rQyVPEGXirf8ChCRf4iQ+v2psAYYRilmd79XR5g1DnFQlnmawcVh9xLg9n/qnMSpVymf/KyQmIz2evhks09uHVriQIg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB40200BA596F107A09BD89DC6A9A20BM1PR01MB4020INDP_"
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: 6d6af4fd-f198-4afb-33dd-08d7f34eb8b8
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 12:52:52.7453 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT029
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mbRN_wRbYK_WVzCxDqGTetH9m2o>
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: Fri, 08 May 2020 12:53:03 -0000

Thanks Michael,

There was ‚Äčanother point we discussed during the interim in context to Capability Indicators: How to arrange the Indicator bits?
a. Using left to right
b. Or using right to left (currently in the draft [1])

If we use right to left then we can give every bit a number, for e.g., currently the 'T' bit is 0x1. The length can be set accordingly i.e. if the indicators are less than 8 bits then the length will be one.
This is simpler to handle in implementation as well. Thoughts?

Best,
Rahul

[1] https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-03#section-5.1.1

________________________________
From: Roll <roll-bounces@ietf.org> on behalf of Michael Richardson <mcr+ietf@sandelman.ca>
Sent: 08 May 2020 02:01 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] capability handling


Rahul Jadhav <nyrahul@outlook.com> wrote:
    > 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?

In some implementations the Neighbor Cache and RIB might come from the same
pool of resources.  Both are lookup /128 and add-header and xmit :-)
(BSD systems merged them back in BSD4.4, as an example)

If a node runs out of RIB entries, it can't add any more grandchildren.
If a node runs out of NC entries,  it can't add any more peers: children or parents.

It seems that we need to collect both information, but we might need to be
clear if they are linked.

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

I have to think more on this.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-