Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range

Jon Mitchell <jrmitche@puck.nether.net> Thu, 20 December 2012 18:05 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 131D121F895C for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 10:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 B+epu+2P0AhZ for <idr@ietfa.amsl.com>; Thu, 20 Dec 2012 10:05:42 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 688E321F8920 for <idr@ietf.org>; Thu, 20 Dec 2012 10:05:42 -0800 (PST)
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 qBKI5fEK008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 13:05:41 -0500
Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBKI5fl1008848; Thu, 20 Dec 2012 13:05:41 -0500
Date: Thu, 20 Dec 2012 13:05:41 -0500
From: Jon Mitchell <jrmitche@puck.nether.net>
To: David Farmer <farmer@umn.edu>
Message-ID: <20121220180541.GC1910@puck.nether.net>
References: <B6B72499-E9D0-4281-84EB-6CA53694866E@juniper.net> <B9358F0B-6AFC-4971-94E9-2C7E44F405AA@juniper.net> <50D1C7F5.6030406@umn.edu> <20121219145706.GA3846@puck.nether.net> <50D3413A.8030904@umn.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <50D3413A.8030904@umn.edu>
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]); Thu, 20 Dec 2012 13:05:42 -0500 (EST)
Cc: "idr@ietf. org" <idr@ietf.org>
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider 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: Thu, 20 Dec 2012 18:05:43 -0000

On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote:
> On 12/19/12 08:57 , Jon Mitchell wrote:
> 
> >Maybe some others would like to weigh in on one of the above options now
> >that it's a focused discussion (otherwise I plan to make the small edits
> >discussed in previous threads and move the start of range to
> >42xxxxxxxx so we can close this out...)
> 
> 
> The idea is to allow the simple regexp of 42???????? to match
> private use ASNs.  However, this makes a few assumptions.

Human identifiable range was the primary concern raised with regex
implementation another given justification for changing the
recommendation to IANA for the start of range.

> 
> 1. While not part of the Private Use ASN range, the intended regexp
> also matches the reserved ASN 4294967295, and therefore 4294967295
> can never be a valid ASN in an AS_PATH.

The draft does not state how to construct a regex, this is out of scope
for the draft.  Some operators may not even choose or need to filter
private use ASN's inbound or outbound based on their
requirements/design.

> 
> 2. The intended regexp would select ASNs beyond the 32bit ASN range,
> if they were valid, that is 4294967296 through 4299999999.
> Therefore, if the ASN range were ever expanded to make these valid
> ASNs, the private use ASN range would also need to be expanded to be
> included these ASNs as well.

Certainly something operators should concern themselves with when
discussions start on moving beyond 4 byte ASNs (maybe a note about it
could be attached to that draft).  On a side note, do you plan on this
before or after IPv6 exhaustion? 

> If we want to use 4.2B as the starting point to simplify regexp
> matching of the private use range then these assumptions need to be
> explicitly stated in the draft.

I disagree, I prefer not delving how to construct regex's properly or
stating how they work in various implementations in a simple IANA
reservation draft.