Re: [Idr] new ID on expansion of private use ASN range

Jon Mitchell <jrmitche@puck.nether.net> Tue, 03 July 2012 20:32 UTC

Return-Path: <jrmitche@puck.nether.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 CDD2121F8562 for <idr@ietfa.amsl.com>; Tue, 3 Jul 2012 13:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPIP9oUHCalX for <idr@ietfa.amsl.com>; Tue, 3 Jul 2012 13:32:45 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6D21F854E for <idr@ietf.org>; Tue, 3 Jul 2012 13:32:45 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q63KWpmj023720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2012 16:32:51 -0400
Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q63KWp4U023717; Tue, 3 Jul 2012 16:32:51 -0400
Date: Tue, 03 Jul 2012 16:32:51 -0400
From: Jon Mitchell <jrmitche@puck.nether.net>
To: Christopher Morrow <morrowc.lists@gmail.com>
Message-ID: <20120703203251.GA6608@puck.nether.net>
References: <20120702164834.GB13713@puck.nether.net> <m2zk7hxli9.wl%randy@psg.com> <20120703141629.GC22598@puck.nether.net> <CAL9jLaa0Q6Zwrce8cxYY_VtDOsnjdQF6gG+bEC3T4LZbJYuZ7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL9jLaa0Q6Zwrce8cxYY_VtDOsnjdQF6gG+bEC3T4LZbJYuZ7w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jul 2012 16:32:51 -0400 (EDT)
Cc: idr@ietf.org
Subject: Re: [Idr] new ID on expansion of private use ASN range
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: Tue, 03 Jul 2012 20:32:45 -0000

On Tue, Jul 03, 2012 at 02:54:29PM -0400, Christopher Morrow wrote:
> On Tue, Jul 3, 2012 at 10:16 AM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
> > that I can walk in and request 10K+ ASNs with minimal justification and
> > low cost.  I don't see much value in increasing the administrative
> 
> I would bet that if you were a large enterprise WAN like, say: "the
> Limited" (clothing store) that has +1.5 endsites, you could say to
> ARIN (for instance): "Hi, I have 1.5k endsites, all connected over a
> third-party WAN, we use BGP and have unique routing policies for each
> site, can I have 1.5k TODAY and since I plan to expand 500 sites this
> year 1k tomorrow" you would probably get that allocated, if you can
> deal with 4-byte.

[JM] Besides filling out 1500 requests, waiting for 1500 tickets to pass
justification, filling out 1500 RSA's with the correct ticket numbers,
and paying $750K upfront and ongoing maintanance to ARIN, what added
benefit would "the Limited" get for using public ASN's in this
presumably non-Internet use case?

> 
> it's worth asking the hostmaster people I suppose.
> 

[JM] Since they seem to be in NoVA, just did.  "Sue" at the ARIN
helpdesk clarified that each request would have to be justified
seperately with diagrams, there are no block assignments, and that she
had not seen a "unique routing" policy justification fly in the many
years she had worked there, only multi-homing requests go through.  She
recommended for the scenario I laid out that I use private use ASNs.

I think what you are proposing is a huge cultural shift / re-education
on the definition of appropriate use of public ASNs, which is certainly
possible but I'm unclear the value proposition since I'm thinking the
existing private ASN's deployed are not going away so we will have to
deal with this new way of using public ASN's for non-public applications
as well as all the knobs around AS_PATH manipulation for overlapping and
private ASN removal as well.  All my proposal does is allow individual
organizations to grow beyond the current range, it does not aim to
address the difficulities of connecting various organizations with
overlapping private use ASNs.