[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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
   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 =-