Re: [Anima] some comments about ACP connect

Brian E Carpenter <> Sat, 16 November 2019 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF5D2120807 for <>; Sat, 16 Nov 2019 15:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OVpDRqXlULiT for <>; Sat, 16 Nov 2019 15:51:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46DFE120025 for <>; Sat, 16 Nov 2019 15:51:16 -0800 (PST)
Received: by with SMTP id n13so8469664pff.1 for <>; Sat, 16 Nov 2019 15:51:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HfkJLJAMv/lGrcFSVDaw1DTA34mMvDc7M6q51FlTOMU=; b=Ci2AeVWGdi/s397n/6yM3DIK/2BYByp8jERtpZ0AT1nPrNphsZEa8ioT0HQnb64okO 6mhbcCGtSteE9Mkd4iiSgNHUrK1XLH3O6AXeebsxCZVa3tZtfzhEMN2AL12FaOI9Defs rej7rxpCOsliYlQMVJgriEkmkpLyRT8o2gpAkItgYG07wrF7GP1F1pHUpqBVy0uwtMtX J878CWZpwCKDydrfl4WJc5sBe5rLJTi5F2eM+XZGGYSR6LYc7Y61rowi5WZ2/Bn/61DL dWkNn767ukNhyNYhEx4yDrYhxkGY1ZZPNDVAMYXvhBdl1hDANT7skX5DrpYN/+dCdZKt CjWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HfkJLJAMv/lGrcFSVDaw1DTA34mMvDc7M6q51FlTOMU=; b=DuNIo56Gr/kpVKoC7jVkm99J5K6QVyeUHdAvGW6r2Dn2eu7YRlpmwIVlHKFm6jMSnu jwrDRpykAe5hxSLZYPZ2gEjBMAD+9IyyjpYJrRr8JspTajFuhHnVQ8s9azRmbnv3iC9R 3hm89HyOPrqrBTTtzpvLgyBTjF3HoeOGQlJ4DJcMp3Ro1zKqEMeTQyNZGSl8jbXWBqeu 09Bwh00MzkMBkWEZOp5+43K14TtMDOzeSzLPZp7TJGbZFcCTzdgch75ClPWXOEmmBiBD A9L/0d7AGtqSDx0geBF2pdoeEkUhdmY0Mw8XYQ9wGGW1HfZVySYU07gdmcKn++XhDL1k ZOyg==
X-Gm-Message-State: APjAAAWaXK0sBqMwfANWq81sozGGANr1JJ09FkUw/RZjIAmF7tJ034NG AexQwI+2db4zP3UMCv/1vFfY1ihx
X-Google-Smtp-Source: APXvYqzO/GMkI6wjx+KaelOb9NWvFTiXRFIpIl8LftpZKBFfks9smcM4XuYKFHtvIE3MqouTWqYT2Q==
X-Received: by 2002:a63:7a50:: with SMTP id j16mr8040491pgn.206.1573948275296; Sat, 16 Nov 2019 15:51:15 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y4sm15378588pfn.97.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 15:51:14 -0800 (PST)
To: Michael Richardson <>,
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 17 Nov 2019 12:51:12 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Anima] some comments about ACP connect
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: Sat, 16 Nov 2019 23:51:18 -0000

On 16-Nov-19 03:20, Michael Richardson wrote:
> Toerless, I am preparing a document on Operational Considerations for
> Registrars: "Operational Considerations for BRSKI Registrar"
> I was reviewing section 8.1, on ACP connect.
>    To allow for auto-configuration of NMS hosts, the ACP edge device and
>    NMS hosts using ACP connect SHOULD support [RFC4191].  The ACP edge
>    device should announce the whole ACP ULA prefix via that standards
>    Router Advertisement signaling option.  It should also announce the
>    default route (::/) with a lifetime of 0.  In result, NMS hosts
>    supporting RFC4191 will route the ACP prefix via the ACP edge device,
>    but will not route the default route via it.
> I don't disagree with anything you say, btw.
> I think that maybe some explanation is in order here though.
> I recognize the document is in it's final stage, but maybe a word or two
> could be added here.
> First, what is the "whole ACP ULA prefix"?  Is it the /48?  I think we
> could say so.
> I will send a pull request once I finish writing.

Assuming it does mean the /48, that's an editorial clarification.
(If it doesn't mean that, please explain.)
> Second, if 6.10.2 defines the base scheme, and it's 8+40+2=50, why in
> 6.10.3 does it
> say "51*" above the "(base scheme)"?  Is that a typo?

Huh? That is not present in the -21 draft.
> It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP
> Connect "LAN"?
> It seems that we ought to sending a Routing Information Option for the
> /48, and a PIO for the specific /64 above.
> We might want to set L=0 here. 
> I understand that we advertise ::/0 with lifetime=0 because of RFC4191
> section 3 analysis.
> I don't know if type A,B,or C hosts are common out there, I think that
> rfc4191 is widely implemented at this point, so I suspect most hosts are
> type C at this point.
> Generally, I think that NOC hosts should not autoconfigure (SLAAC or
> stable private address) addresses, as they ought to be manually
> configured.  I am open to discussion here.

I can see that for conventional management tools. I will just observe
that GRASP discovery doesn't need to be seeded with any well known
addresses (except the GRASP LL multicast address) so GRASP is completely
indifferent to how NOC hosts get their unicast addresses. In fact we
could easily create a full NOC discovery mechanism over GRASP. I built
a MUD Manager discovery mechanism in the hackathon yesterday, and any
NOC server could be discovered the same way. It's probably worth
re-reading RFC8368 before discussing further.

(In my code, I gave preference to ULAs over GUAs, but GRASP doesn't even
care about that).


> I do think that they should
> listen to RAs for the ACP route so that we can have multiple routers, etc.
> *
> I will be making a few more specific recommendations in my document in
> line with the view above.
> _______________________________________________
> Anima mailing list