[Roll] do capabilities need to understood, can they be added?
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 August 2019 00:46 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 C5FA1120818 for <roll@ietfa.amsl.com>; Mon, 26 Aug 2019 17:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 JMoJryIWXOCo for <roll@ietfa.amsl.com>; Mon, 26 Aug 2019 17:46:47 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879A8120817 for <roll@ietf.org>; Mon, 26 Aug 2019 17:46:46 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C2A0B380BE for <roll@ietf.org>; Mon, 26 Aug 2019 20:45:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63259AD4 for <roll@ietf.org>; Mon, 26 Aug 2019 20:46:45 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com>
References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 26 Aug 2019 20:46:45 -0400
Message-ID: <22118.1566866805@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/T9oIaqgHflgIVcTJIWqySiNJItQ>
Subject: [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: Tue, 27 Aug 2019 00:46:50 -0000
I asked: 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. 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). 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. 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. 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. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Roll] comments on mopex-cap-00 Michael Richardson
- Re: [Roll] comments on mopex-cap-00 Rahul Arvind Jadhav
- Re: [Roll] comments on mopex-cap-00 Pascal Thubert (pthubert)
- Re: [Roll] comments on mopex-cap-00 Michael Richardson
- [Roll] do capabilities need to understood, can th… Michael Richardson
- Re: [Roll] do capabilities need to understood, ca… Rahul Arvind Jadhav
- Re: [Roll] do capabilities need to understood, ca… Michael Richardson
- Re: [Roll] do capabilities need to understood, ca… Pascal Thubert (pthubert)
- Re: [Roll] do capabilities need to understood, ca… Pascal Thubert (pthubert)
- Re: [Roll] do capabilities need to understood, ca… Michael Richardson
- Re: [Roll] do capabilities need to understood, ca… Michael Richardson
- Re: [Roll] do capabilities need to understood, ca… Pascal Thubert (pthubert)