Re: [Anima] some comments about ACP connect

Michael Richardson <mcr@sandelman.ca> Thu, 28 November 2019 09:39 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D481200C7 for <anima@ietfa.amsl.com>; Thu, 28 Nov 2019 01:39:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.446
X-Spam-Level: *
X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 TASiHWlpyY16 for <anima@ietfa.amsl.com>; Thu, 28 Nov 2019 01:39:08 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96A61200B9 for <anima@ietf.org>; Thu, 28 Nov 2019 01:38:42 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [185.201.63.254]) by relay.sandelman.ca (Postfix) with ESMTPS id 752851F47D; Thu, 28 Nov 2019 09:38:40 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4FB6CE65; Thu, 28 Nov 2019 17:38:29 +0800 (+08)
From: Michael Richardson <mcr@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: anima@ietf.org
In-reply-to: <f2d7fac0-1bbd-c8cf-fe22-f8a79dd2a978@gmail.com>
References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> <f2d7fac0-1bbd-c8cf-fe22-f8a79dd2a978@gmail.com>
Comments: In-reply-to Brian E Carpenter <brian.e.carpenter@gmail.com> message dated "Sun, 17 Nov 2019 12:51:12 +1300."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 28 Nov 2019 10:38:29 +0100
Message-ID: <22922.1574933909@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/mHguAw4lpde3oSxxlxpvRqhepsA>
Subject: Re: [Anima] some comments about ACP connect
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 09:39:10 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> 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.

I seem to have been working from what was in github in order to better
provide edits.  That was a mistake I now see as the github hasn't been
maintained.  I'm fixing that...

I see that the -21 text seems a bit better, and the third paragraph mentions
the /48 explicitely.

I also see that the 6.10.3 is already fixed.

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

We will have quite a number of convential management tools in the NOC.
The need to be able to reach out from operator desktop to equipment with SSH
(or gosh... telnet?) will persist into the future, and it's why we built and
secured the ACP.

Many existing services will need names, and while putting ULAs into DNS might
surprise some IPv4 operators, I think it's completely sane.

A question will be how to connect the current crop of management tools to the
ACP. This can be done by literally connecting desktops via ACP Connect.
Another way will involve putting bastion hosts (ssh-jump-hosts) into the NOC,
as well as hosting virtual desktops on hypervisors connected via ACP Connect.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [