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

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

Hi,

Thanks for this interesting draft.

First, here is one of the definitions:

>       CASM Coordinator: A management system which has a centralized
>       database manage the overall address pools and allocate address
>       pools to the device in the devices.

Ther is no need for this database to be centralized or for the
allocation of address pools to be centralized. It can be done with
a completely distributed system. (I agree that centralized logging
might be needed.) In fact, sections 4.2 and 4.3 describe a centralized
model for everything, not just for logging.

Could we perhaps agree that this is only one possible architecture?
If so, we would also need a second draft describing a distributed
architecture. It's quite hard to cover both designs in one document.

>    The overall procedure is as follows:
> 
>    o  Operators will configure remaining address pools centrally in the
>       Address Pool Management System (APMS).  There are multiple address
>       pools which can be configured centrally.  The APMS server will
>       then divide the address pools into addressing unit (AU) which will
>       be allocated to the agent in devices by default.

Certainly the NOC will configure initial address pools into a master agent.
But from that moment, a distributed process can take over in which pools
(prefixes) will allocated to distributed agents on demand, with no need
for default allocations.

>    o  If the lifetime of the address pool is going to expire, the DA
>       should issue an AddressPoolRenew request to extend the
>       lifetime,including the IPv4, IPv6, Ports, etc.

A couple of questions on this.:

1. Why is the lifetime useful? Firstly, once an address has been
allocated to an end-user, it must be left there as long as necessary;
you can't recover an address while it is in active use. That will
block the address pool that contains it indefinitely, so what is the
value of the lifetime? Secondly, if there is no lifetime, the agent
can release the address pool on demand if it is not in use. Again,
there is no value in the lifetime that I can see.

2. Is it really useful to include the notion of ports in an address
pool? In the case of IPv6 it is definitely useless. In the case of
IPv4 with A+P (port-based address sharing, RFC6346), surely you never
want to share a single address across different agents? That would
lead to complex and fragile CASM operations at rather high frequency.
RFC6346 defines how A+P gateways may talk to each other (horizontally,
not north-south) to share an address using A+P. You seem to be
duplicating that function. Also, RFC7768 seems to assume that port
sharing occurs entirely within a single CGN. So it seems to me that
it's wrong to include port ranges in the CASM model.

(Note: I have no problem with 'port-range' being defined in the
CASM YANG model; that seems necessary for completeness. My problem
is with using it in network-wide resource management, which doesn't
seem reasonable.)

> 5.1.1.1.  Address pools
...
>    o  IPv6 addresses

I suggest dividing this into 'Globally routable' and 'ULA'

>    o  MAC Addresses

Can you explain this? Where do layer 2 addresses fit in?

...
>   Multicast address pool:

This topic needs more discussion.

Regards
   Brian