Re: [Anima] some comments about ACP connect

Toerless Eckert <tte@cs.fau.de> Sun, 17 November 2019 06:38 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 895A1120089 for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 22:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.941
X-Spam-Level:
X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 U4waNiRLwZ0y for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 22:38:30 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC20412007C for <anima@ietf.org>; Sat, 16 Nov 2019 22:38:29 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 60ABD548029; Sun, 17 Nov 2019 07:38:24 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 50B10440055; Sun, 17 Nov 2019 07:38:24 +0100 (CET)
Date: Sun, 17 Nov 2019 07:38:24 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima@ietf.org
Message-ID: <20191117063824.GD56410@faui48f.informatik.uni-erlangen.de>
References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> <f2d7fac0-1bbd-c8cf-fe22-f8a79dd2a978@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f2d7fac0-1bbd-c8cf-fe22-f8a79dd2a978@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/MeVjoGhR4cniySn6iCCVSqmaHAM>
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: Sun, 17 Nov 2019 06:38:32 -0000

On Sun, Nov 17, 2019 at 12:51:12PM +1300, Brian E Carpenter wrote:
> > 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).

Rereading Michaels sentence again after my previous email answer,
i would lke to double down on what Brian said:

today, there is a lot of manual configuration of NOC server IP addresses
on each route for various services. The DNS-SD drafts i wrote (expired,
to be revived, when i got ACP off my back) are exactly to overcome this
problem by learning via DNS-SD (ACP GRASP as transport ;-) those NOC
host services.

Once you have this service discovery, NOC hosts do not need well-known
IP addresses anymore, but can use SLAAC, or DHCP on the ACP connect LAN
- whatever the operator prefers. Of course, ther is IMHO no need for
DHCP, but its likely that in the non-ACP part of the network, some
service parameters may still be learned from DHCP (such as DNS servers),
and i have seen few deployments that tried to combine DHCP service
discovery with SLAAC address assignment. Besides, there is also litte
address tracking with SLAAC, and operators like to be able to track
addresses. Aka: As long as we do not have stronger arguments either way,
i wouldn't get into the middle of the SLAAC vs. DHCP debate. I just
want to make sure that we do not need well-known IP addresses.

Cheers
    Toerless