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

Brian E Carpenter <> Wed, 22 March 2017 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7ED19131754 for <>; Wed, 22 Mar 2017 06:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OWXPHNiQ_YSw for <>; Wed, 22 Mar 2017 06:46:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55E20131753 for <>; Wed, 22 Mar 2017 06:46:47 -0700 (PDT)
Received: by with SMTP id z13so65861283iof.2 for <>; Wed, 22 Mar 2017 06:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=845TVJos2Y98OFDsf5zC0S5c64s6OrrcdDpph1jPlTk=; b=Yjpf8grnJr7iVNNjQ3AxraxGUB6kY63KRM5hl5V983G7iLyE/CYP+pilHgCCwIMipM AW1ATouSb+lLZ+mMwe7yqkOfeadzBI8MrF3VchrojWGoafRrPlUPMxM8sQAuxvmsLtex Af2+9P8PHV7Dg49OfWlSZIkeVR0TdUXNYeS4nyCxOac20ZqxyvAdowwDgUdKqlYvvUMy YWvyrUuyc8XrunVjt4XiBRZSWkrwxoJJX9KQm6moLcTDlgqhHRwteOJ0jkuotWZ/k22L f+QkzTugkblSfJq9Kma+4+fXquea5FpQ19goqEVC9zk80oaDuvqjPyDFHgQ0GeLPNj0X n9hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=845TVJos2Y98OFDsf5zC0S5c64s6OrrcdDpph1jPlTk=; b=Y7BasVUU35/8D8nZatVAQKMQnYqVgRmpr7tqFfHA4P5OhyGit0oY4XOAlGdxoXUiT5 jsouuptDjwaU9R8Fv7X08wnxvu3vBt5fHdlZ5xpvNhpQOgigwwVOZdZfF2LVeUAszg/x rlbOBuiyZ4ckOBOnoer0YfdhZ6C2wKSd8MAL5QNvw5BIJgC+2Hp3t2rVGop0h9FfyQmQ XORB8MdYy8qoTUAGLwDuAH+WzHs5oclzwl3cDVBJ8Mdu7Gx9ULEBJOL0idNcoJ6vuLvY YPCFgO94lbJ7HKPCR2WIaNsMoypyVB05UwBnAdey2nZAE9yt42/3hFYJ/Dhbp7VMznd5 aw1Q==
X-Gm-Message-State: AFeK/H3O6cSXC6WIF7Grh+/aviPOyi56KRGouTSl+vhF2RlS3bF//uaes/xCEIYjhC9pUA==
X-Received: by with SMTP id 63mr35934937iog.6.1490190406440; Wed, 22 Mar 2017 06:46:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r10sm824900iod.33.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 06:46:45 -0700 (PDT)
To: MarcoH - lists <>,
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 23 Mar 2017 02:46:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Casm] New Version Notification for draft-xie-ps-centralized-address-management-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Centralized Address Space Management <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Mar 2017 13:47:12 -0000

On 22/03/2017 20:58, MarcoH - lists wrote:
>> 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
> 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.

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 IPv6 prefixes, without the need to go full static (which would remove a lot of the benefits in efficiency).

Policy of this kind should be configurable, IMHO.