Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

Toerless Eckert <> Mon, 25 September 2017 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6D5313457C; Mon, 25 Sep 2017 13:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BtirwK2OiChb; Mon, 25 Sep 2017 13:18:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C83E13306A; Mon, 25 Sep 2017 13:18:19 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:77]) by (Postfix) with ESMTP id 22F7D58C4EB; Mon, 25 Sep 2017 22:18:15 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 0B721B0CCC7; Mon, 25 Sep 2017 22:18:14 +0200 (CEST)
Date: Mon, 25 Sep 2017 22:18:14 +0200
From: Toerless Eckert <>
To: Michael Richardson <>
Cc: Brian E Carpenter <>,,
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Sep 2017 20:18:21 -0000

On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
>     brian> Toerless explained elsewhere why he thinks the duplication is
>     brian> needed.
> I read that after my email.
> I simply can't agree.

I don't think i was suggesting duplication. I was suggesting for
one document to define an extensibel objective and the other draft to
extend it. 

The extensibel notation i was suggesting would also result in the
definition of a brski-enrol service name that would be useable outside
of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

>     >> ====== section 11
>     >> This document may be considered to be updating the IPv6 addressing
>     >> architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
>     >> addresses ([RFC4193]) depending on how strict specific statements in
>     >>
>     >> I don't like this statement.  Either it violates the spec, and updates it, or
>     >> it does not.  I do not think that it violates.  This is not a multi-link
>     >> subnet, this is a prefix that is not on-link.
>     brian> As readers of the 6man list know, this has been a very contentious topic.
>     brian> I think it's safer to duck it in the ACP draft: say what we do, but say
>     brian> nothing about RFC4291 etc.
> I agree.

I can easily remove the whole section 11 from the ACP document and we can bring it
back if/when 6man review is asking for it, no problem.

>     >> It is possible, that this scheme constitutes an update to RFC4191
>     >> because the same 64 bit subnet prefix is used across many ACP
>     >> devices.  The ACP Zone addressing Sub-Scheme is very similar to the
>     >> common operational practices of assigning /128 loopback addresses to
>     >> network devices from the same /48 or /64 subnet prefix.
>     >>
>     >> It does not. Brian? Do you concur?
>     > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign
>     > them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that
>     > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links").
>     > But we don't need to apologise. As you say, we're simply assigning /128
>     > addresses to (virtual) interfaces using our own scheme. And we're relying
>     > on BCP 198 (RFC 7608) which says that routing prefixes can be any length
>     > up to /128. If you want to cite anything, cite RFC 7608.
> Toerless, do you want text to say this?

Always happy to get text suggested, but please also with a fitting place,
especially if you do not like section 11. And then do not blame me if we
again get more and more explanatory text into standards sections ;-P (which i do
like, but which normal IETF reviewer usually bitch about).

>     draft> The goal for the 8 or 16-bit addresses available to an ACP device in
>     draft> this scheme is to assign them as required to software components,
>     draft> which in autonomic networking are called ASA (Autonomic Service
>     mcr> We are not providing 8-bit or 16-bit IIDs.
>     mcr> We are providing 256 or 65536 /128 addresses which are conveniently
>     mcr> aggregated for routing purposes.

Hmm... I guess you are implying but also prefer not to explicitly say:
-> If an implementation wants to pick any shorter than /127 prefix from thiss
block of addresses to assign to a subnet, then it's up to that implementation
to argue how such an implementation will fit the IPv6 architecture. The 
ACP document does no require or prescribe any such approaches.

>     draft> In practical terms, the ACP should be enabled to create from its /8
>     draft> or /16 prefix one or more device internal virtual subnets and to
>     draft> start software components connected to those virtual subnets.
>     mcr> No, don't say this, and don't do this in practice.  Create /128 routes to LL
>     mcr> address of the internal VM and configure the /128 as a loopback address
>     mcr> inside the VM.
>     brian> So yes, I concur with Michael.

Ok, let me see how to best deal with this all.

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