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

Jon Mitchell <jrmitche@puck.nether.net> Tue, 03 July 2012 01:55 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 8816011E8104 for <idr@ietfa.amsl.com>; Mon, 2 Jul 2012 18:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.997
X-Spam-Level:
X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.602, 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 p22FEvpzEjrk for <idr@ietfa.amsl.com>; Mon, 2 Jul 2012 18:55:16 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6111E8102 for <idr@ietf.org>; Mon, 2 Jul 2012 18:55:15 -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 q631tLME028496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2012 21:55:21 -0400
Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id q631tLcX028495; Mon, 2 Jul 2012 21:55:21 -0400
Date: Mon, 02 Jul 2012 21:55:21 -0400
From: Jon Mitchell <jrmitche@puck.nether.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Message-ID: <20120703015521.GB22452@puck.nether.net>
References: <20120702164834.GB13713@puck.nether.net> <20120702184737.GV18361@pfrc>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20120702184737.GV18361@pfrc>
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]); Mon, 02 Jul 2012 21:55:21 -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 01:55:16 -0000

Comments [JM] inline...

On Mon, Jul 02, 2012 at 02:47:37PM -0400, Jeffrey Haas wrote:
> 
> On Mon, Jul 02, 2012 at 12:48:34PM -0400, Jon Mitchell wrote:
> > I hope you can take some time from the normal debate(s) to consider and
> > review a fresh draft on expanding the ASN space reserved for Private
> > Use.  All comments regarding content, clarity or structure welcome.
> 
> You beat me to such a draft.  I had one about 2/3 finished and just got
> diverted from finishing it. :-)  I thus, obviously, support a draft on this.

[JM] Thanks.

> 
> I would also suggest that GROW is probably a more appropriate venue for this
> draft.

[JM] I have mixed feelings on this which I expressed to both WG chairs,
where the main points for thinking it should be in IDR are:
  1. This is an update to RFC 1930 which is listed as an IDR document,
     albeit very old.
  2. Documentation ASN reservation RFC was published more recently by
     IDR.
  3. GROW charter is focused on Internet scalability and routing, where
     private Use ASN use cases (most?) often involve non-Internet
     routing.

A good case can be made for either in my opinion, but the IDR WG chairs
were OK with it being worked here.  I can definitely send it also to
GROW list for comment either before or after it becomes a WG document,
or whatever makes the IDR WG chairs most comfortable.  GROW WG chairs
are aware of it already...

> 
> I suggest that we leave 65535 alone as a reserved AS.

[JM] I think it should be clarified either way, and I think adding it to
the private use ASN range with this draft is the better approach for the
following reason.  I consider this an after-the-fact registration (RFC
5226 section 6.3) since this ASN seems to have widespread (mis-)use as
many implementations strip it using their remove private ASN knobs and
various networks undoubtedly have it deployed since it seems more than
since a large amount of Internet documentation including RFC 1930 seem
to include it as a private Use ASN.  Also, if this document progress,
implementors will need to update their knobs and documentation anyway,
so they, IETF and IANA can all be on the same page, allowing this ASN to
be stripped if there are vendors that don't do it today (note even some
vendors with published documentation stating that private ASN range is
64512-65534 strip 65535 with their remove private knobs).

> 
> I finally suggest that the number of private ASes (967K) is somewhat weird
> and would be a counter example of an implementor that would like something
> that made a bit more sense boundary-wise.  (It makes staring at the private
> stuff in the debugger a bit easier.)

[JM]  I don't feel strongly either way, expect others will weigh in on
size, placement, and structure of range.  I leaned toward the range
being easily recognizable which is why I choose a nice round number for
the start meaning operators would recognize 4294 (it will be hard to
optimize for both, but frankly anything at the end of the total range of
space should be easily recognizable since is not likely to be assigned
by an RIR for a long time).  Can I suggest your alternative proposal for
folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or
are you suggesting a different range location or sizing?