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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 May 2017 13:57:57 +1200

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

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 May 2017 17:30:14 +0800

Hi，Brian, 

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

Chongfeng　
 
Hi,

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

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. 

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

 
 
...

Regards
   Brian
 
_______________________________________________
CASM mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/casm