Re: [Casm] I-D Action: draft-li-casm-address-pool-management-arch-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 22 March 2017 19:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: casm@ietfa.amsl.com
Delivered-To: casm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EAC1294FB for <casm@ietfa.amsl.com>; Wed, 22 Mar 2017 12:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 OGERG-RWNm6u for <casm@ietfa.amsl.com>; Wed, 22 Mar 2017 12:32:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDE7129C04 for <CASM@ietf.org>; Wed, 22 Mar 2017 12:32:06 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E38C205A4 for <CASM@ietf.org>; Wed, 22 Mar 2017 15:55:36 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D3248636BB for <CASM@ietf.org>; Wed, 22 Mar 2017 15:32:04 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: CASM@ietf.org
In-Reply-To: <29263994-2dfe-ad98-750a-ff0f7024cb2d@gmail.com>
References: <148912379958.5722.2883329103732032085@ietfa.amsl.com> <29263994-2dfe-ad98-750a-ff0f7024cb2d@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 22 Mar 2017 15:32:04 -0400
Message-ID: <27551.1490211124@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/OQE788UbL3PHM0mNfhkg0YBOD0U>
Subject: Re: [Casm] I-D Action: draft-li-casm-address-pool-management-arch-00.txt
X-BeenThere: casm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Centralized Address Space Management <casm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/casm>, <mailto:casm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/casm/>
List-Post: <mailto:casm@ietf.org>
List-Help: <mailto:casm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/casm>, <mailto:casm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 19:32:16 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> APMS A management system which has a centralized databse manage the
    >> overall address pools and allocate address pools to the device in the
    >> devices.

    > Again, although a central database is the traditional approach, we must
    > be open to a scalable approach and that means distribution. Certainly
    > there must be an *initial* pool that originates by human action in the
    > NOC. But that does not require a central database that records every
    > detail.

It would be good if whatever data format we come up to describe the prefixes
was also the format that ARIN/RIPE/etc. used/returned.
This would eliminate certain amounts of human-induced errors.

    > If an ISP has say a /29 and is delegating /48 to subscribers, it has to
    > manage up to 2**19 prefixes. That isn't an impossible size for a
    > central database, but it is large. (And this is a small ISP.)  The
    > problem becomes much easier if you distribute it among, say, 100 agents
    > spread around the network.

If you think about it, while in theory the ISP has to manage all that space,
actually, it just needs to have an entry for each customer.
Since it has to have an entry in a database for each customer anyway, a few
more bytes for a prefix isn't that big a deal in the whole scale of things.

[And, an ISP with 2**19 customers is doing quite well, so it can well afford
to manage that size of database :-)]

Unless pushed by some government mandated forced roll, I think that in v6,
ISPs will start to realize it's better to just allocate a prefix to a
customer, and when the customer is gone, never reuse that space until they
run out (LRU).

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