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

Sorry, I have been rather busy so did not reply promptly.
See comments in line:

On 17/05/2017 21:30, xiechf.bri@chinatelecom.cn wrote:
> 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.

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

That seems to be an area full proprietary solutions, as far as I can see. 
The idea of a standardized practice is to allow multivendor solutions.
As far as I know, this isn't described in any IETF documents. Maybe you
have a reference? Whether the carriers in general want that, I don't know.
But if they do want it, it would be a topic for the IETF, I think (in
liason with BBF).

My assumption is that current distributed BNG solutions depend on a
systematic algorithm for assigning prefix pools to BNGs, from a central
pool. With autonomic solutions, we are aiming at complete demand-driven
flexibility in assigning prefixes to edge routers. That process could be
the same for BNGs as for the devices in a Radio Access Network.

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

Yes. That is exactly what will happen in an autonomic solution, except
that all assigments will be drive by demand, with no central action
except to define the initial central pool.

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

Yes, I understand that is necessary at the local level, but why is
it necessary to consider it as a parameter of an address pool
in the data model? It seems like a parameter of the individual
DHCP server, not a parameter of the address itself.

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

OK, but that is not very clear in the draft.

Thanks
    Brian

>> 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
> 
> 
> 
> _______________________________________________
> CASM mailing list
> CASM@ietf.org
> https://www.ietf.org/mailman/listinfo/casm
> 