Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

Geoff Huston <gih@apnic.net> Thu, 29 November 2012 20:04 UTC

Return-Path: <gih@apnic.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313E221F8B8B for <idr@ietfa.amsl.com>; Thu, 29 Nov 2012 12:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdHpCPzgo3s3 for <idr@ietfa.amsl.com>; Thu, 29 Nov 2012 12:04:02 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3149A21F8997 for <idr@ietf.org>; Thu, 29 Nov 2012 12:04:02 -0800 (PST)
Received: from 2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-3448-34ba-4195-613f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:3448:34ba:4195:613f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B8FC4B6745; Fri, 30 Nov 2012 06:03:59 +1000 (EST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="windows-1252"
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li>
Date: Fri, 30 Nov 2012 07:03:58 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <135D3112-A4CB-4B88-AD4A-5A34706566C5@apnic.net>
References: <B6B72499-E9D0-4281-84EB-6CA53694866E@juniper.net> <2CDB688B-9C24-4AF5-8900-20A88211AC54@apnic.net> <1AF020BC-65F1-4484-AAAD-355A294A7692@kumari.net> <CEEF8969-16D0-42B9-A093-F058E5D1848F@apnic.net> <574CC47E-4BF6-4749-8B44-CFA526ECDFD6@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: Apple Mail (2.1499)
Cc: "idr@ietf. org" <idr@ietf.org>
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2012 20:04:03 -0000

On 30/11/2012, at 5:55 AM, Tony Li <tony.li@tony.li> wrote:

> 
> On Nov 29, 2012, at 10:21 AM, Geoff Huston <gih@apnic.net> wrote:
> 
>> But if there is a single need for 100,000 code points in single coherent space then you have to ask how one could ensure uniqueness within the deployment space, as you are now talking about a large number of entities and a large coder point space, and according to your response, the reason why there is a driving need  duplicate an existing uniqueness framework is because the current framework we have for ensuring uniqueness of AS number code points is ... "inelegant"?
> 
> 
> Obviously, the private use ASNs would have local uniqueness and specified by the local administration.  Not a big deal.


aaahhh scoped uniqueness

I seem to recall an IPv6 scoped address concept along these lines... thats right ... site local.

"Not a big deal"?

In V6 this concept of scoped uniqueness with a local administration caused massive heartache and was dropped. Are we going to repeat this exercise again and again in different code point spaces? Or are we going to try and understand some more basic architectural considerations that are at play here that imply that the imposition of scope as a moderation of the concept of uniqueness  is often an arbitrary affair that generates way more exceptions and consequent failures than there are strictly conformant cases.


>  More to the point, the noise and fluff of administering this is not something that you want foisted on the RIRs, especially when multiplied by the number of sites using it.
> 

On the other hand, I believe that the RIR's have been foisted with that role from day one.

> We've seen over and over again that the right way of creating scalability is to create hierarchy.  All this is doing is to continue its instantiation.


I fail to appreciate this logic - creating a larger swamp space of clashing private use ASN code points hardly seems to me to be consistent with an objective of underpinning scalable uniqueness in the use of code points in networking.

And yes, I'm still opposed to the progress of this draft from WG Last Call to the IESG.

Geoff