Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT)

Warren Kumari <warren@kumari.net> Thu, 14 December 2017 01:59 UTC

Return-Path: <warren@kumari.net>
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 D6D34128799 for <anima@ietfa.amsl.com>; Wed, 13 Dec 2017 17:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 A_9rwrPFOl6P for <anima@ietfa.amsl.com>; Wed, 13 Dec 2017 17:59:27 -0800 (PST)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0AC127B52 for <anima@ietf.org>; Wed, 13 Dec 2017 17:59:25 -0800 (PST)
Received: by mail-wr0-x22d.google.com with SMTP id v22so3838832wrb.0 for <anima@ietf.org>; Wed, 13 Dec 2017 17:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Tcsogh2jRkd5hWxihEdHrX3pVbXnAI0Ch8TWmi4R+A=; b=rwV6w2Vt6nTblby7Idb/OPrrrkA/8X2DDb1fx1sfivNIOjyDbfbR6iVlA12gXCl9ym RkzAkxvS6e9/5NMjQfULonvFjTpEZY3FmtGhSRTQm+xtPKPBLxjY+N1rdZ0BnwqlMiaH MtjkKKw2yd5fMvaNEghVX0LdtUOLpRRix2BBlzX3bc6znUH2oBE9ecP77/q8qZvfCo3H GN0eBx1MYJ8slmMa4f8qLAYRrP9kMX6f2LWiGxzc3xeHB/1KpYSrUOawT5CZNutDhJ7O 4KfUoSEjFaFPF0g03BnfxzXMhDL4v9dfcl6AvxK1Pt0eanHK3B3fzpenq+4bSn5R8fOW U8kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Tcsogh2jRkd5hWxihEdHrX3pVbXnAI0Ch8TWmi4R+A=; b=UwL0RCcA1a/w95yrcOy1CZkSjmJYqsSY6CywKHcCutMx/QoDaFF94oj2BdIjS6waof vF7qrcX2e6OpZ9e9zZcDitUJ/YK8NHNFK0tuXaXkgdf3vZQDvMIO8F8virU/gCKpOXVG OZyxeX5ID/hbLCEa6seaaKpeL7UocKlQSHwWT8tapsg8Lou6OBbg+H1mf5sWC5jDEiTY jUO19MnhL5RC9ECOHPLhExnzzRBbV/SpFtymEsyXqG4+KS7HZNG8l8NCJsGQda816+GV Oo/RUCzudtrq+4nd//yu1KnQmfo1Zs1gTy+9tWzZ38IIZPryem8kMIYE0tjpN/wjYnBm xWxg==
X-Gm-Message-State: AKGB3mJmdu3/Mb8tP9cvW+BT6EwM9PmnwFqirUgFW+dPQZyHSBWzo+BR tmNKeJnMtJMZof50liEeBQXYqQQ6Pbps2Ca4e4ZQIg==
X-Google-Smtp-Source: ACJfBotScZMbbPCYIjopKmg9bARGotf7QD2GBQoak3tejH9ISBFSGu6gAnkiqW/c16qwfvnS4ZqPnoGSUq5nVbMEdZ4=
X-Received: by 10.223.201.139 with SMTP id f11mr1899154wrh.283.1513216763623; Wed, 13 Dec 2017 17:59:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Wed, 13 Dec 2017 17:58:43 -0800 (PST)
In-Reply-To: <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com>
References: <151319810418.30121.10020770638906816886.idtracker@ietfa.amsl.com> <1fceefc8-e874-33f5-705c-268db9314aed@gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 13 Dec 2017 20:58:43 -0500
Message-ID: <CAHw9_iLCDuvDtTj3W+vPJ2iPhSDmYtCXpBy7dBxbi6mZsm5TiQ@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-prefix-management@ietf.org, Toerless Eckert <tte@cs.fau.de>, anima-chairs@ietf.org, tte+anima@cs.fau.de, anima@ietf.org, Fred Baker <fredbaker.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/aDmAU1bVxlDP2chYVxsYbJcVIuM>
Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT)
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: Thu, 14 Dec 2017 01:59:29 -0000

Ok, I'm happy.

If you do update, I think that the last point is the most confusing,
and needs the most work, but I'm as I said, I'm a happy camper.
W

On Wed, Dec 13, 2017 at 7:48 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 14/12/2017 09:48, Warren Kumari wrote:
> ...
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you.
>>
>> I did have some comments / questions.
>> I'd also like to draw both the authors, and AD's attention to Fred Bakers
>> excellent thoughts in his OpsDir review -
>> https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-06-opsdir-lc-baker-2017-10-23/
>>
>> Firstly, a global concern:
>> This technique (and I suspect many automated prefix allocations where a device
>> uses space, and then requests more) is likely (I think) to result in
>> fragmentation of the address space - this will lead to more routing entries in
>> the IGP, which may be an issue for smaller routers or "L3 switches". I think
>> that it would be useful to note this.
>
> That devil is in the details, but you're correct, that is a risk. How big a risk
> depends on the algorithms and policies used. If we get to update the draft,
> this would be a good point to add.
>
>>
>> I also wanted to make sure that the author of this document were aware of the
>> CASM BoF from IETF98 - I've just checked, and see that at least Qiong Sun was
>> associated with the work (draft-xie-ps-centralized-address-management).
>
> Yes, in fact it would mesh quite nicely with CASM. That's the main reason
> I pushed to have the C in CASM mean "coordinated" instead of "centralized".
>
>> I had a question -- I don't really understand what: [Page 9] "A gateway router
>> in a hierarchical network topology normally provides prefixes for routers
>> within its subnet, ..." is trying to say. I've seen many "hierarchical network
>> topologies" and don't believe this to be true, nor do I really understand what
>> "its subnet" means. In some cases a router will announce an aggregate for
>> customers behind it, but I don't really view that as a general case. I'm
>> guessing I'm just not understanding - can you please educate me?
>
> Hmm. In a manually designed network (especially with v6) I'd expect
> the initial design would be done in something close to a binary tree,
> but in the real world things tend to drift from that starting point
> over the lifetime of the network. But I think the phrasing is probably
> trying to say too much in too few words. All it's really trying to say
> is that the ability to negotiate with an arbitrary peer is more powerful
> than only being able to ask your upstream for more prefixes.
>
> Again, happy to clarify the wording if we update the draft again.
>
>    Brian
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf