Re: [Anima] some comments about ACP connect

Toerless Eckert <tte@cs.fau.de> Sun, 17 November 2019 06:32 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 1521612009C for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 22:32:05 -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 FmiuZW_BJda9 for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 22:32:03 -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 D3F2B12007C for <anima@ietf.org>; Sat, 16 Nov 2019 22:32:02 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 32744548029; Sun, 17 Nov 2019 07:31:58 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B463440055; Sun, 17 Nov 2019 07:31:58 +0100 (CET)
Date: Sun, 17 Nov 2019 07:31:58 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org
Message-ID: <20191117063158.GC56410@faui48f.informatik.uni-erlangen.de>
References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ZMgXW5YW9WTkXc7K2chyu_94lEM>
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:32:05 -0000

Thanks, Michael.

Given how i may not 100% observe the github, make sure you also send
email when oyu have proposed fixes.  Please also use the latest xml on
datatracker as the authoritative soucrce. I already missed one
github feedback from you earlier. I apologize, but i am not the
fluent github user yet.

On Fri, Nov 15, 2019 at 10:20:25PM +0800, Michael Richardson wrote:
> 
> 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 can not find this particular version of the paragraph in any version.
Which version of the ACP draft is this from ?

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

The document is not using the term "whole" in conjunction with "ACP
prefix" and the acronym section (2.) defines "ACP (ULA) prefix(es)"
as /48 bit prefixes.

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

The 51 below the (base scheme) in 6.10.3 was fixed to 50 in revision -09.

> It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP
> Connect "LAN"?

Yes, except that you would then need to figure out how to assign fitting
/64 bit host-parts with Registrar-ID and Node-Number to non-autonomic
devices on that autonomic-connect LAN. Hence the introduction of the
Manual addressing scheme that does not have this expectation against the
/64 host part.

Aka: use the manual addressing sub-scheme. Where "manual" means
"not managed by registrars".

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

Probably faster if you spend some in-person cycles with me on those
parameters as i do not have those route advertisement details memorized
as much as you may have.

> 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 do think that they should
> listen to RAs for the ACP route so that we can have multiple routers, etc.

The whole idea of the text is to exactly allow for whatever host-address
part allocation people feel most comfortable with and not predicate any
preference. DHCP, SLAAC, whatever. The only thing the document tries to
say is how to ensure that hosts which are multi-homed with such an
acp-connect LAN being one of its subnets - would route all ACP
prefixes to the ACP edge node, but not a default-route.

So i hope we are in violent agreement here. If you think there is text
missing, plase suggest.

> I will be making a few more specific recommendations in my document in
> line with the view above.

Thanks
    Toerless