[arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments

Thu May 7 17:59:25 EDT 2009

heh... One more round.. Last time I swear. :)

"unifying the two pools is unnecessary" is a point that may be being overlooked.

It may not be clear to everyone that ARIN issues in numerical order, and that 393,225 (the next available, lowest 4-byte ASN) is at the back of the line in a unified pool structure.

Cheers,
Aaron

On Thu, May 07, 2009 at 05:45:04PM -0400, Chris Malayter wrote:
> Just to give a little background, there's a lot of information out there
> on this issue.  It's likely that other RIR's will run out of 16bit ASN's
> before ARIN does if they do not create a re-allocation policy to help
> their 16bit pools last after their block allocations come to an end.
> Vendor support is VERY scattered depending on vendor and platform.  Greg
> Henkins at F10 and I have done several presentations on this very topic at
> past NANOGs/GPF's/APRICOT's.  The bottom line is that AS23456 is not a
> very scalable nor workable solution for many people.  I think inevitably
> we are going to have to extend the 32 bit deadline to accommodate
> vendors integration into mainline builds for legacy equipment that is
> still being supported.  From the data I've been looking at July of 2011
> appears to be the exhaust for the first RIR.  As such, I am fine with
> the way that this policy is written, though I think some flexibility put
> into the policy for the cutoff for 32bit only asns might be the best
> bet.
> 
> -Chris
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Hughes
> Sent: Thursday, May 07, 2009 5:36 PM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Extend 16 bit ASN Assignments
> 
> Fellow PPML participates,
> 
> Just to make sure this is 100% clear.  RIPE is very likely to run out of
> 16bit ASNs next year as they appear to have no reclamation process
> (based on the 8 blocks of 1,024 ASNs recently assigned by IANA to the
> RIPE region). This means, operator support will happen.
> 
> ARIN, on the other hand, will have 16 bit ASNs to give out until ~2013.
> If we simply let ARIN give out 16it until they run out and they start
> issuing 32bit, we will get BOTH the benefit of continuing to hand out
> 16bit ASNs AND push for operational support.
> 
> Global proliferation of 4-byte ASNs in 2010-2011 is a foregone
> conclusion.  More to the point, ARIN has ~3.5 years of 2-byte inventory
> because of their efficiency. So the proposal to stop ARIN from unifying
> the two pools is unnecessary.
> 
> Cheers,
> Aaron
> 
> On Thu, May 07, 2009 at 01:51:51PM -0700, Aaron Hughes wrote:
> > 
> > I oppose this policy as written.
> > 
> > Looking at ARIN's historical statistics, it appears as though ARIN
> issues 1,600 to 1,700 ASNs each year.
> > 
> > Looking at IANA's stats:
> > 35840-36863 Assigned by ARIN 2005-02
> > 39936-40959 Assigned by ARIN 2006-03-29
> > 46080-47103 Assigned by ARIN 2008-03-27
> > 53248-54271 Assigned by ARIN 2009-04-21
> > 54272-55295 Assigned by ARIN 2009-04-21
> > Excluding April 2009, ARIN has only requested 3,072 ASNs since
> February 2005.
> > 
> > Looking again at ARIN's historical statistics, they have issued 6,550
> ASNs from 2005 through 2008, but have only gotten 3,072 ASNs from the
> IANA.
> > 
> > Where's the difference?
> > In San Antonio, Leslie gave a presentation that included information
> about returned and revoked ASNs. Slide 10 of the presentation indicates
> 4,357 ASNs have been returned to ARIN since January 2005.
> > 
> > So it looks like ARIN is recycling unused ASNs, prolonging the
> lifespan of the free 16-bit ASN pool.
> > Projecting this forward, at current consumption rates it should take
> approximately 32 months for ARIN to use up the 2,048 ASNs issued on
> 2009-04-21 by IANA, which puts us somewhere near December 2012.
> > 
> > ARIN's historical statistics:
> > https://www.arin.net/knowledge/statistics/historical.html
> > IANA's stats:
> > http://www.iana.org/assignments/as-numbers/
> > Presentation foils:
> >
> https://www.arin.net/participate/meetings/reports/ARIN_XXIII/ppt/wednesd
> ay/rsd.ppt
> > 
> > Cheers,
> > Aaron
> > 
> > 
> > On Thu, May 07, 2009 at 01:19:36PM -0700, Scott Leibrand wrote:
> > > I disagree.  We are still waiting to get a release of the code train
> we 
> > > use on the Cisco 7600 platform that supports 32-bit ASNs.  It sounds
> 
> > > like they're finally getting close, but I think a further extension 
> > > probably would be helpful.
> > > 
> > > We'll have a much better view of what's required by the fall
> meeting, 
> > > when this is up for discussion.  Since that will be our last chance
> to 
> > > change policy before the current 1 Jan 2010 deadline, I definitely
> think 
> > > this needs to be on the agenda.
> > > 
> > > -Scott
> > > 
> > > Owen DeLong wrote:
> > > > NIT:  The revised text of 5.1 (or at least specific amendments to
> it) 
> > > > should be
> > > > stated as part of the Policy statement. The rationale section is
> not a 
> > > > binding
> > > > part of the policy.
> > > >
> > > > Substance: This policy simply isn't needed. Current software for
> most
> > > > routers supports 32 bit ASNs. There's been ample warning for
> providers
> > > > and other organizations to update their management systems,
> scripts,
> > > > etc. If they haven't done it by now, they are only going to do it
> in 
> > > > response
> > > > to the change actually happening.  Putting it off further does not
> really
> > > > benefit the community.
> > > >
> > > > I am opposed to this policy as written.
> > > >
> > > >> ## * ##
> > > >>
> > > >>
> > > >> Policy Proposal Name: Extend 16 bit ASN Assignments
> > > >>
> > > >> Proposal Originator: Marla Azinger
> > > >>
> > > >> Proposal Version: 1
> > > >>
> > > >> Submission Date: 6 May 2009
> > > >>
> > > >> Proposal type: Modify
> > > >>
> > > >> Policy term: Permanent
> > > >>
> > > >> Policy statement: This proposal is to modify section 5.1 in the
> NRPM to
> > > >> extend the 16-bit ASN assignment timeframe for one more year
> further
> > > >> than the current text. The expiration requiring removal of
> section 5.1
> > > >> is also being removed.
> > > >>
> > > >> Rationale:
> > > >>
> > > >> Currently users of 32-bit ASN?s are encountering technical issues
> that
> > > >> they can?t immediately overcome and therefore require 16-bit
> ASN?s to
> > > >> operate. As a result in the ARIN region to date, 204 of the 216
> 32-bit
> > > >> ASN?s that have been assigned have been returned and exchanged
> for a 16
> > > >> bit ASN. On 1 JAN 2010 ARIN policy declares zero distinction
> between
> > > >> 32-bit and 16-bit ASN?s. This proposal is to change the date on
> the
> > > >> third line of NRPM 5.1 and extend the timeframe for 16 bit ASN?s
> to be
> > > >> assigned. If these changes are made then ARIN RIR ASN policy will
> read
> > > >> clearly and remove any misconceptions of 16-bit cutoff post run
> out and
> > > >> enable technology to catch up to the ASN bit change. The
> expiration date
> > > >> that requires removal of section 5.1 after zero distinction
> occurs is to
> > > >> be removed. Instead section 5.1 will be left in place in the NRPM
> for
> > > >> value added historical purposes.
> > > >>
> > > >> The revision of 5.1 would read as follows:
> > > >>
> > > >> 5.1 16-bit and 32-bit AS Numbers
> > > >>
> > > >> ? Commencing 1 January 2007, ARIN will process applications that
> > > >> specifically request 32-bit only AS Numbers and assign such AS
> numbers
> > > >> as requested by the applicant. In the absence of any specific
> request
> > > >> for a 32-bit only AS Number, a 16-bit only AS Number will be
> assigned.
> > > >>
> > > >> ? Commencing 1 January 2009, ARIN will process applications that
> > > >> specifically request 16-bit only AS Numbers and assign such AS
> Numbers
> > > >> as requested by the applicant. In the absence of any specific
> request
> > > >> for a 16-bit only AS Number, a 32-bit only AS Number will be
> assigned.
> > > >>
> > > >> ? Commencing 1 January 2011, ARIN will cease to make any
> distinction
> > > >> between 16-bit only AS Numbers and 32-bit only AS Numbers, and
> will
> > > >> operate AS number assignments from an undifferentiated 32-bit AS
> Number
> > > >> pool.
> > > >>
> > > >> Terminology
> > > >>
> > > >> ? "16-bit only AS Numbers" refers to AS numbers in the range 0 -
> 65535
> > > >>
> > > >> ? "32-bit only AS Numbers" refers to AS Numbers in the range
> 65,536 -
> > > >> 4,294,967,295
> > > >>
> > > >> ? "32-bit AS Numbers" refers to AS Numbers in the range 0 - 
> > > >> 4,294,967,295
> > > >>
> > > >> Timetable for implementation: Immediate
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> PPML
> > > >> You are receiving this message because you are subscribed to
> > > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > >> Unsubscribe or manage your mailing list subscription at:
> > > >> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > >> Please contact info at arin.net if you experience any issues.
> > > >
> > > >
> ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to
> > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > --
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > 
> > -- 
> > 
> > Aaron Hughes 
> > aaronh at bind.com
> > (703) 244-0427
> > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> > http://www.bind.com/
> > -- 
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> -- 
> 
> Aaron Hughes 
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> http://www.bind.com/
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 

Aaron Hughes 
aaronh at bind.com
(703) 244-0427
Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
http://www.bind.com/