IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 02 September 2019 18:04 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 CFB7E12004E for <roll@ietfa.amsl.com>; Mon, 2 Sep 2019 11:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YARQudxqoQqU for <roll@ietfa.amsl.com>; Mon, 2 Sep 2019 11:04:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC20120047 for <roll@ietf.org>; Mon, 2 Sep 2019 11:04:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E751D380BE for <roll@ietf.org>; Mon, 2 Sep 2019 14:02:59 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DCC2BE47 for <roll@ietf.org>; Mon, 2 Sep 2019 14:04:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <MN2PR11MB356586AD1BAF9B31CBC53648D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> <22118.1566866805@localhost> <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com> <MN2PR11MB3565DED578369DCA9B1BE4E4D8BE0@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB356586AD1BAF9B31CBC53648D8BE0@MN2PR11MB3565.namprd11.prod.outlook.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, 02 Sep 2019 14:04:16 -0400
Message-ID: <4903.1567447456@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/222Wdc74N5fOQBip_3CHltEbcec>
Subject: Re: [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: Mon, 02 Sep 2019 18:04:35 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > In addition to the below I took a refresh look at RFC 6551.

    > https://tools.ietf.org/html/rfc6551#section-3.1 provides a shell for capabilities such as those that we are after.
    > And
    > https://tools.ietf.org/html/rfc6551#section-3.2 discusses how to handle
    > a resource that varies over time and is subject to consumption and
    > exhaustion. Storage of routes for P-DAO has similarities with that.

    > All in all I'm thinking that we could extend Node Metric/Constraint
    > Objects and how they are used for DODAG formation. We could for
    > instance use the metric container as defined for DIO and create at
    > least one new message to report to the asker for the reasons below.

So, we'd (ab)use node metrics to provide information from children to parents
(and possibly to root) on what the node can do?

They (DAG Metric Containers) are options, and live in DIOs or DAOs, so would
still be limited as to how they flow up/down the DAG.  This just changes how
we encapsulate the options, but does not change the rules on where the information flows.

The point of introducing the NAO was that it would have different rules about
where it goes?

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

v2.15.0 | Report a Bug | By Email