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

[Brian E Carpenter <[e-mail]>]

On 23/03/2017 08:32, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> 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