Re: [Anima] ACP RPL root

Benjamin Kaduk <> Wed, 08 July 2020 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFDA73A0FCC for <>; Tue, 7 Jul 2020 19:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5bFguylRbaY0 for <>; Tue, 7 Jul 2020 19:21:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79D163A0FA1 for <>; Tue, 7 Jul 2020 19:21:32 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 0682LRWL026969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 22:21:30 -0400
Date: Tue, 7 Jul 2020 19:21:26 -0700
From: Benjamin Kaduk <>
To: Michael Richardson <>
Message-ID: <>
References: <8942.1594172879@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8942.1594172879@localhost>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Anima] ACP RPL root
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2020 02:21:37 -0000

On Tue, Jul 07, 2020 at 09:47:59PM -0400, Michael Richardson wrote:
> Ben, is this DISCUSS comment still alive?

>From memory, I think it's been resolved.

I'm sure that a discuss about whether/how the RPL root is automatically
determined got resolved for *some* document, but am not 100% sure if it was
this one or one of the 6TiSCH ones.  In any case, the discussions that
preceded that resolution also served to educate me about some of the finer
points that I had completely missed with my original comment, and that
education (combined with your description below) convinced me that there's
not a (certainly discuss-level, and probably not any) issue here.


> > Section places a normative ("SHOULD") requirement on the RPL
> > root, but if I understand correctly the RPL root is automatically
> > determined within the ACP, and thus the operator does not a priori know
> > which node will become the RPL root.  Am I misunderstanding, or is this
> > effectively placing this requirement on all ACP nodes?
> In LLNs, it is common to designate a specific, high-capacity node as the RPL
> root.
> In particular, in non-storing mode, the RPL root has to keep a RIB and FIB
> for every single node, while the other nodes need only three to five FIB
> entries to keep track of parents and active children.
> We are using storing mode, so every node already has to have the capacity to
> have a RIB and FIB on the order of the number of ACP nodes.
> This is not arduous for an Enterprise or ISP class router.
> That's the major cost of being the root: the root has to have a complete
> table. (But, in storing mode, we only have next-hop, not the full path)
> As originally envisioned, the automonic network should be self-forming and
> self-healing, which means that partitions of the network should recognize
> that there is no root, and choose one.  That level of autonomy is not
> reached in this document, or in the ANIMA architecture. In fact, that
> level of autonomy got spun off as the SUPA WG.
> So, yes, in theory, all ACP nodes could be the RPL root, and when they do,
> they need to install blackhole route for ULA space fd00::/10 in order to
> prevent loops.  This shouldn't be a big deal.
> The RPL DODOG root will in mature situations be the ACP registrar,
> and while the market is less mature, in an router designated as the
> ACP-connect.
> --
> Michael Richardson <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-