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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Mar 2017 11:05:42 +1300

Hi,

Thank you for this draft. I have a few general comments, let me start with the Abstract:

>    it is complicated to
>    manually configure the address pools on lots of Broadband Network
>    Gateways(BNGs) for operators.

Not only for BNGs. I believe the same problem arises in any kind of large
network. Also, although the IPv4 exhaustion is a problem, so is the enormous
size of the IPv6 space - it also needs coordinated management.

> By introducing SDN/NFV in BNG, the

The problem exists without SDN and NFV. I agree that virtualization of
any kind makes the problem bigger, but it doesn't *create* the problem.

>    address pools can be allocated in a centralized way.

As we have already discussed, the *requirement* is coordination, not
centralization. In fact, again considering the enormous IPv6 space
within a carrier, a distributed solution seems unavoidable in the
long run.

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

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.

Apart from that comment I like your model with numerous agents
in the network. Actually it corresponds very closely to the ANIMA
model except that we will distribute the function of the APM server
among those agents. In my toy implementation I found that it was
necessary to define an initial "master" agent that provides the
initial pool - the difference from your APM server is that the master
is identical to all the other agents except for having the initial pool.
(However, I repeat that this is a toy, not a serious implementation.)

I look forward to discussions in Chicago.

Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Mar 2017 15:32:04 -0400

Brian E Carpenter <[email-masked]> 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.

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Mar 2017 11:16:06 +1300

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

> customer, and when the customer is gone, never reuse that space until they

Indeed. But that can be done locally or centrally.

    Brian