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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 22 March 2017 22:16 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 D43D5128CFF for <casm@ietfa.amsl.com>; Wed, 22 Mar 2017 15:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fhRPVY_T5nxQ for <casm@ietfa.amsl.com>; Wed, 22 Mar 2017 15:16:01 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 230CF127735 for <casm@ietf.org>; Wed, 22 Mar 2017 15:16:01 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id w124so30815651itb.1 for <casm@ietf.org>; Wed, 22 Mar 2017 15:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=kBTdV1SW1DrXFb74VLUf43D2h7zwzfaiMnpHdKFTrOM=; b=UjTWFtbRZ8k+KNb/dQw4Iuv9znHvgFz7jllAOT+TnqG5datIupEEsAMiUSBx+sd4zk zrphnSLJQsyFaS77K6Xq7evDFmuIWnIcemZ5IhtDB0WQ7Iv7aQaM4yy2/OAQ1LK+JuxN EUjUV8pUq0RG1iPGVFddnzyd9rf42ZvffUZlVh2e26e6jyrSfSjVejb2EH1N+jk4xwAu G+RYg7M3Ipu3M/tMvWZhvVQFVhp46Xs+xWkVltrx8sSUSPPHxorKmVeRFczg//FlJjDB HTfo9UkRA2/Dvwci35oY5nfxjSe/NXaTyYYEHODvNMsRxqBaFKZFAkxyHDTgtB5F/3dY Dq9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kBTdV1SW1DrXFb74VLUf43D2h7zwzfaiMnpHdKFTrOM=; b=pcSxPdxoqDUL3Nnx4OGo6+rm7LP2AMFLPY6ibPsHBbGr+OlsLoIKR5Rrz6u39Bb8AG DnkDRXC4ablB4GpFJ5gSJnjyYiCFL9PiiKhKw88FjDmFMkbumsmSnPxYc4wTeiPQZr7B RFjWXSlXDiJ2CIgTUHGVYcvBAKiz4yReo5OTL5vnQcirLMCJYDS/PTpovFCLSV9w23+n YiRjlCWzhvAFKYtEMikyFbYcrmiGRfNlcLMbBhSXVChEb6u/LjhpefUNMbK6YozM6ski kFOt1Mkxg06FPCx8qA8hHMsdsSFypS9C/XE2lTSnOPZlOYOsXxpwfH73Fte5W3lqjxSR X/Gw==
X-Gm-Message-State: AFeK/H1V+gQgdFJp4D6HB//r32LdhHm63y7IME7gPYZIuQUxBA9raYc5wr2yEglGmRZMmQ==
X-Received: by 10.36.213.3 with SMTP id a3mr10310470itg.30.1490220960376; Wed, 22 Mar 2017 15:16:00 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m63sm1443302ioa.15.2017.03.22.15.15.59 for <casm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 15:15:59 -0700 (PDT)
To: casm@ietf.org
References: <148912379958.5722.2883329103732032085@ietfa.amsl.com> <29263994-2dfe-ad98-750a-ff0f7024cb2d@gmail.com> <27551.1490211124@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <b79e3b1e-37b5-87de-2da3-ea3f24b44525@gmail.com>
Date: Thu, 23 Mar 2017 11:16:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <27551.1490211124@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/rJMAH2Ui0PUbr1gDKjbvzfJjhtU>
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 22:16:03 -0000

On 23/03/2017 08:32, Michael Richardson wrote:
> 
> 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.

True, but the point here is that we shouldn't constrain the solution to
that particular model by saying that this state MUST be centrally maintained.

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

Indeed. But that can be done locally or centrally.

    Brian