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

Hi，Brian, 

       Thank you for your comments, pls see inline for more comments．

Chongfeng　

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.

 Chongfeng: 　Centralized and distributed is a different way of implementation, in the traditional network, usually using a distributed approach, the distributed approach is not excluded, and CASM focus on centralized solutions.　In the centralized address resource management architecture, the allocation of address blocks is determined by the CASM Coordinator, which requires the maintenance of allocated, unallocated address block, and therefore requires a database to hold such information. And also, it maintains log information.

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.

 Chongfeng: 　Yes, as mentioned earlier, centralized is a possible architecture. A typical distributed example is BNG, which assigns addresses to end users. It is a way that has existed for a long time, should not need the standard, right? 

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

Chongfeng:　 In the initial state, CASM Coordinator assign address pools to the Agent in the device. Then, In the process of running, if the Agent's address pool resources have been used up, the Agent need to apply more address blocks; In addition, when the address pool usage is too low, the Agent can release a part of the address blocks to CASM Coordinator. 

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

Chongfeng:　　For DHCP Server service, lifetime is an important parameter, it need specify Lifetime, for the DHCP server to assign addresses to the end user, control the available time, in addition, when the end user abnormal off-line, DHCP Server need to recycle the address by Lifetime expiration. 

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

Chongfeng:　As we know, the range of ports is 1 to 65535, but during NAT use, only a portion is available for use, such as 2048 to 65535. I agree with what you said "RFC7768 seems to assume that port compromised by within a single CGN", Here it used in north-south, and used to set the range of ports that NAT can use. Usually, IPv4 and port are used together. 

> 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

_______________________________________________
CASM mailing list
CASM@ietf.org
https://www.ietf.org/mailman/listinfo/casm