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

Michael Richardson <> Sat, 23 September 2017 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76063126D0C; Sat, 23 Sep 2017 12:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6TzHqtRyl-dr; Sat, 23 Sep 2017 12:35:35 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id C230E126C0F; Sat, 23 Sep 2017 12:35:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D494B2009E; Sat, 23 Sep 2017 15:40:21 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 44751806CE; Sat, 23 Sep 2017 15:35:33 -0400 (EDT)
From: Michael Richardson <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: MH-E 8.6; nmh 1.6+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: Sat, 23 Sep 2017 15:35:33 -0400
Message-ID: <>
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: Sat, 23 Sep 2017 19:35:37 -0000

Toerless, thank you for this version.  We are very very close!
Brian, Max, I invoke your name in my comments... please read and +1,
or disagree with me.

I noticed in this version has two places with no space after the .:

 	   across the network.[RFC7575] defines the fundamental ideas and design
           and it should be re-usable by all autonomic functions.[RFC7575]

Can we avoid semantic/normative statments like "ACP routing table may include
multiple" in a terminology section?

ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
 	      normal/simple case, the ACP has one ULA prefix, see Section 6.10.
 	      The ACP routing table may include multiple ULA prefixes if the
 	      "rsub" option is used to create addresses from more than one ULA
 	      prefix.  See Section 6.1.1.  The ACP may also include non-ULA
 	      prefixes if those are configured on ACP connect interfaces.  See
 	      Section 8.1.1.

  ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
 	      normative case, the ACP has one ULA prefix as specified in
              Section 6.10.  The cases where multiple prefixes are present
              are explained in Section 6.1.1, and use of non-ULA prefixes
              are explained in Section 8.1.1.

There are some good updates to the ACP domain.  I want to bring up this issue
From BRSKI here:

I was suggesting that the information for the Pledge's CSR should be broken
up such that the pledge will create the right CN from the pieces, which it
needs to know anyway. I had suggested:

   "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001",
                    "acp-prefix-length": 96,
                    "acp-plus-part": "area51.research",
                    "acp-domain": ""

I don't like your text:
           If the operator does not own any FQDN, it should
 	   choose am FQDN format string that intends to be equally unique.

I suggest that:
  If they don't own any FQDN, then, aside from WTF?, that they form a
  unique name as: $(uuidgen)
  Or, perhaps that they use ${ULA}

the only real-life situation where this is going to happen is in a test lab
run by co-op students, and in that case, the software might as well have a
pre-configured default.


Brian, Max and I asked you to remove the EST requirements on announcements
From the ACP document.

   ACP secure channel MUST imediately be terminated when the lifetime of
 	   any certificate in the chain used to authenticate the neighbor
 	   expires or becomes revoked.  Note that is is not standard behavior in
 	   secure channel protocols such as IPsec because the certificate
 	   authentication only influences the setup of the secure channel in
 	   these protocols.

This is rather impractical to implement in real life, that's why IPsec
doesn't do that.  I strongly suggest you sit down with some Cisco, Juniper
(Netscreen) and Checkpoint IPsec product managers, and ask them what they
actually do, and why.

Assuming you really want to have this kind of behaviour, then the correct way
to do this is to make statements about the rekey intervals on the channels.

   ACP secure channels created with the use of certificates will include some
       lifetimes for the certificates. The set of lifetimes includes:
                 1) the expiry date of the certificate
                 2) the lifetime of the OCSP response
                 3) the validity time of the CRL response

       The earliest date provided by these provides a time at which the
       keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed.

6.10.4.  ACP Manual Addressing Sub-Scheme

   The sub-scheme defined here is defined by the Type value 1 (one) in

was changed to:
   The sub-scheme defined here is defined by the Type value 00b (zero)

I think that this is a typo, and should be 01b ?
Or does the Manual mechanism somehow fit into the
   ACP Zone Addressing Sub-Scheme because the Z bit is different?

Do you explain this manual zone better somewhere?

Can you show the two Types with their bits set at the end of the base scheme?

                64                             64
    |    (base scheme)  01|Subnet-ID| Z ||     Interface Identifier    |
    <-------48--------->TT    13      1

section 8.8.1, starting at:
        The ACP connect interface must be (auto-)configured with an IPv6

seems to be missing articles and/or words, and needs an english editing pass.

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

        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?
        The goal for the 8 or 16-bit addresses available to an ACP device in
        this scheme is to assign them as required to software components,
        which in autonomic networking are called ASA (Autonomic Service

We are not providing 8-bit or 16-bit IIDs.
We are providing 256 or 65536 /128 addresses which are conveniently
aggregated for routing purposes.

 	   In practical terms, the ACP should be enabled to create from its /8
 	   or /16 prefix one or more device internal virtual subnets and to
 	   start software components connected to those virtual subnets.

No, don't say this, and don't do this in practice.  Create /128 routes to LL
address of the internal VM and configure the /128 as a loopback address
inside the VM.

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