Subject: [Casm] Fw: New Version Notification for draft-xie-ps-centralized-address-management-02.txt

From: "Xie Chongfeng" <[email-masked]>
Date: Mon, 13 Mar 2017 11:39:07 +0800

A new version of I-D, draft-xie-ps-centralized-address-management-02.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.
 
Name:           draft-xie-ps-centralized-address-management
Revision:       02
Title:          Problem statement for centralized address management
Document date:  2017-03-12
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-xie-ps-centralized-address-management-02.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-ps-centralized-address-management/
Htmlized:       https://tools.ietf.org/html/draft-xie-ps-centralized-address-management-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-xie-ps-centralized-address-management-02
 
Abstract:
   The increase in number, diversity and complexity of devices and
   services in modern networks bring new challenges for the management
   of network resources, such as IP addresses, network prefixes, bandwidth,
   and services that utilize such resources. This draft contains a problem
   statement for IP address management and defines requirements with
   practical use cases provided by operators.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat

---

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

Hi,

This draft makes a strong case for coordinated address management.
In my opinion, it makes no case at all for *centralized* address
management. But apart from that one word to change, I think it's
very good.

Regards
   Brian Carpenter

On 13/03/2017 16:39, Xie Chongfeng wrote:
> _______________________________________________
> CASM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/casm
>

---

From: MarcoH - lists <[email-masked]>
Date: Wed, 22 Mar 2017 11:58:43 +0400

> management. But apart from that one word to change, I think it's

Tend to agree here, while I can see how the word “centralised” came in, we might be better off if this project would use the term “coordinated” address management where possible.

Further in response to the draft, Section 5 “requirements” in the second 2nd bullet reads:

"A fast return of unused resources for reassignment is of high value.”

While I can see this as a value for scarce resources such as IPv4 addresses or IP port ranges, I am not sure if this is a beneficial property for IPv6, where networks should be able to afford themselves the luxury of providing hosts with a stable address (prefix) when they require it.

For now I can probably live with the terminology used, but would like to see some clarification on how this requirement will be further expanded and refined to allow for more stable or predictable IPv6 prefixes, without the need to go full static (which would remove a lot of the benefits in efficiency).

Thanks,

MarcoH

---

From: "Xie Chongfeng" <[email-masked]>
Date: Wed, 22 Mar 2017 17:31:00 +0800

Hi, Brian, 

Thank you for your view to the use case , and we are looking forward to receiving more comments from you.

Best regards
Chongfeng  

[email-masked]
 
From: Brian E Carpenter
Date: 2017-03-22 06:48
To: [email-masked]
Subject: Re: [Casm] Fw: New Version Notification for draft-xie-ps-centralized-address-management-02.txt
Hi,

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Mar 2017 02:46:52 +1300

> While I can see this as a value for scarce resources such as IPv4 addresses or IP port ranges, I am not sure if this is a beneficial property for IPv6, where networks should be able to afford thems…

Yes, policy details will be different for IPv6. For example, I believe that some registries (manually) over-allocate IPv6 requests so that a later request for more space can be allocated contiguously. But the principle that free resources can be made available immediately is important. In a distributed solution that is easy; the resource does not need to be "returned", it is simply available when a peer asks for it.

> For now I can probably live with the terminology used, but would like to see some clarification on how this requirement will be further expanded and refined to allow for more stable or predictable…

Policy of this kind should be configurable, IMHO.

    Brian