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

Toerless Eckert <tte@cs.fau.de> Mon, 25 September 2017 20:18 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 B6D5313457C; Mon, 25 Sep 2017 13:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 BtirwK2OiChb; Mon, 25 Sep 2017 13:18:19 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C83E13306A; Mon, 25 Sep 2017 13:18:19 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 22F7D58C4EB; Mon, 25 Sep 2017 22:18:15 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0B721B0CCC7; Mon, 25 Sep 2017 22:18:14 +0200 (CEST)
Date: Mon, 25 Sep 2017 22:18:14 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
Message-ID: <20170925201814.GB9705@faui40p.informatik.uni-erlangen.de>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <11713.1506195333@obiwan.sandelman.ca> <235c34a0-415e-5580-7308-58cf19131f3d@gmail.com> <23496.1506346820@obiwan.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <23496.1506346820@obiwan.sandelman.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/MESiOSi0zsG5alfKXFalEqtn-Jo>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 25 Sep 2017 20:18:21 -0000

On Mon, Sep 25, 2017 at 09:40:20AM -0400, Michael Richardson wrote:
>     brian> Toerless explained elsewhere why he thinks the duplication is
>     brian> needed.
> 
> I read that after my email.
> I simply can't agree.

I don't think i was suggesting duplication. I was suggesting for
one document to define an extensibel objective and the other draft to
extend it. 

The extensibel notation i was suggesting would also result in the
definition of a brski-enrol service name that would be useable outside
of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

>     >> ====== 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.
> 
>     brian> As readers of the 6man list know, this has been a very contentious topic.
>     brian> I think it's safer to duck it in the ACP draft: say what we do, but say
>     brian> nothing about RFC4291 etc.
> 
> I agree.

I can easily remove the whole section 11 from the ACP document and we can bring it
back if/when 6man review is asking for it, no problem.

>     >> 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?
> 
>     > Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign
>     > them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that
>     > sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links").
>     > But we don't need to apologise. As you say, we're simply assigning /128
>     > addresses to (virtual) interfaces using our own scheme. And we're relying
>     > on BCP 198 (RFC 7608) which says that routing prefixes can be any length
>     > up to /128. If you want to cite anything, cite RFC 7608.
> 
> Toerless, do you want text to say this?

Always happy to get text suggested, but please also with a fitting place,
especially if you do not like section 11. And then do not blame me if we
again get more and more explanatory text into standards sections ;-P (which i do
like, but which normal IETF reviewer usually bitch about).

>     draft> The goal for the 8 or 16-bit addresses available to an ACP device in
>     draft> this scheme is to assign them as required to software components,
>     draft> which in autonomic networking are called ASA (Autonomic Service
> 
>     mcr> We are not providing 8-bit or 16-bit IIDs.
>     mcr> We are providing 256 or 65536 /128 addresses which are conveniently
>     mcr> aggregated for routing purposes.

Hmm... I guess you are implying but also prefer not to explicitly say:
-> If an implementation wants to pick any shorter than /127 prefix from thiss
block of addresses to assign to a subnet, then it's up to that implementation
to argue how such an implementation will fit the IPv6 architecture. The 
ACP document does no require or prescribe any such approaches.

>     draft> In practical terms, the ACP should be enabled to create from its /8
>     draft> or /16 prefix one or more device internal virtual subnets and to
>     draft> start software components connected to those virtual subnets.
> 
>     mcr> No, don't say this, and don't do this in practice.  Create /128 routes to LL
>     mcr> address of the internal VM and configure the /128 as a loopback address
>     mcr> inside the VM.
> 
>     brian> So yes, I concur with Michael.

Ok, let me see how to best deal with this all.

> 
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
tte@cs.fau.de