Re: [Roll] do capabilities need to understood, can they be added?

Michael Richardson <> Mon, 02 September 2019 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAF0D120072 for <>; Mon, 2 Sep 2019 10:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3aM1BYksW_K6 for <>; Mon, 2 Sep 2019 10:00:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CF2A12004E for <>; Mon, 2 Sep 2019 10:00:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D476380BE for <>; Mon, 2 Sep 2019 12:58:42 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id F10E7C5E for <>; Mon, 2 Sep 2019 12:59:58 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-Reply-To: <>
References: <> <> <22118.1566866805@localhost> <> <>
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, 02 Sep 2019 12:59:58 -0400
Message-ID: <22489.1567443598@localhost>
Archived-At: <>
Subject: Re: [Roll] do capabilities need to understood, can they be added?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Sep 2019 17:00:13 -0000

Pascal Thubert (pthubert) <> wrote:
    pt> Seems to me that sometimes the capability of the node is something that
    pt> only the root cares about.

Yes, agreed.  This was my case (1), which I've brought up.

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

    pt> At least that's true when the root needs to know if all nodes support a
    pt> capability. It wants to flood a query and gather the responses from
    pt> all. Missing queries would mean a unicast retry I guess.

Agreed. That's my case (2).

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

Phase 1 is to learn whether all the nodes support it.
Phase 2 is to tell the nodes whether they can turn it on or not.

could be done this way, btw.

    > At other times it might be something that the parent cares about. In
    > that case it asks one or all of its children.

Yes. That's my case (4).

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

    > So we're after a capability exchange flow that is unicast or multicast,
    > with a unicast response. Either from parent to child or from root to
    > any. The flow would be independent of the storing vs. non-storing MOP.


    > We do not really have a flow like that in RPL. It's akin to a software
    > update, when the root wishes to now if all nodes have received the full
    > image.

So, you are suggesting that any reply from the nodes to the root shouldn't
use DAO, but something new.    I don't see why we can't put the downward
signal into the DIO though.

    > The DIO could be stretched to convey the ask to a group, but it's hard
    > to make it reliable. The DAO even less OK since it carries destination
    > not node information. As of today the root does not really know if
    > multiple addresses are on a same node.

    > All in all it seems that we are after something that is needed by RPL
    > but on the side of the current protocol. I'm not too sure that we
    > should overload the current messages for this. Rather, we may build new
    > objects for Nodes information and capability. Like a unicast or
    > multicast NIS (Node Info Solicitation) and a NAO (Node Advertisement
    > Object). We'd design operations that are independent of the current
    > MOPs. Note that we could use local broadcast NAO to discover siblings
    > and siblings siblings, something P DAO needs anyway.

I am for NAO as always being from node to root.
I see how we could do this multicast for P-DAO, but I think that I need to
know more.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-