RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished
Dear colleagues, The RIPE NCC has less than 100 32-bit Autonomous System Numbers (ASNs) available in its pool. Given current assignment rates, we expect that we will run out of 32-bit ASNs before May 2013. We will soon begin to assign 16-bit ASNs for all requests until our pool has been replenished by IANA. This will not result in any operational issues for requestors as 16-bit ASNs are compatible with equipment designed to run BGP. This situation was anticipated and covered during the RIPE NCC Registration Services update during the RIPE 65 Meeting. You can see the details in the "Feedback from RIPE NCC Registration Services" presentation available at: <https://ripe65.ripe.net/programme/meeting-plan/address-policy-wg/> -------------------------- Replenishing our ASN Pool -------------------------- The RIPE NCC requests additional ASNs from IANA based on "IANA Policy for Allocation of ASN Blocks to RIRs: <https://www.ripe.net/ripe/docs/ripe-480> Under this policy, we need to demonstrate 80% usage of "the previously received ASN block" (which includes both 16-bit and 32-bit ASNs we received from IANA on 3 March 2012) to replenish our ASN pool. We are expecting to reach this usage rate within six to eight months. The RIPE NCC will return to the usual procedure of assigning 32-bit AS numbers "by default" once our ASN pool is replenished. -------------------------------------------------------------------- Background on 32-bit ASN assignments in the RIPE NCC service region -------------------------------------------------------------------- The RIPE NCC assigns ASNs based on the "Autonomous System (AS) Number Assignment Policies and Procedures": <https://www.ripe.net/ripe/docs/ripe-52>. In accordance with the RIPE Address Policy Working Group decision, announced at: <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2010-January/004977.html>, the RIPE NCC assigns 32-bit ASNs by default unless a 16-bit ASN is specifically requested. As a result of this practice, 32-bit ASNs are currently supported by most vendors and routed globally. Of the 3,400 32-bit ASNs in the global routing table, 64% were assigned by the RIPE NCC within its service region (Europe, the Middle East and parts of Central Asia). Best regards, Andrew de la Haye Chief Operations Officer RIPE NCC
Hi, On Thu, Mar 14, 2013 at 09:52:08AM +0100, Andrew de la Haye wrote:
The RIPE NCC has less than 100 32-bit Autonomous System Numbers (ASNs) available in its pool. Given current assignment rates, we expect that we will run out of 32-bit ASNs before May 2013. We will soon begin to assign 16-bit ASNs for all requests until our pool has been replenished by IANA. This will not result in any operational issues for requestors as 16-bit ASNs are compatible with equipment designed to run BGP. This situation was anticipated and covered during the RIPE NCC Registration Services update during the RIPE 65 Meeting.
Under this policy, we need to demonstrate 80% usage of "the previously received ASN block" (which includes both 16-bit and 32-bit ASNs we received from IANA on 3 March 2012) to replenish our ASN pool. We are expecting to reach this usage rate within six to eight months.
Mh, not April first. Seriously, where has this gone wrong? the utilization rate of 16Bit ASNs should not be a measure for replenishing the 32 bit Pool. It should never have been. This way you're actually forced to hand out 16bit ASNs BEFORE your 32bit pool runs out because there shouldnt be the situation that when somene explicitely asks for a 32bit ASN RIPE NCC is not able to "supply" one. Rico. MfG/regards, -- Rico Gloeckner Sr. System Engineer Amtsgericht Nuernberg, HRB 18320 Geschaeftsfuehrer: Oliver Kuegow, Richard Mueller
Under this policy, we need to demonstrate 80% usage of "the previously received ASN block" (which includes both 16-bit and 32-bit ASNs we received from IANA on 3 March 2012) to replenish our ASN pool. We are expecting to reach this usage rate within six to eight months.
Mh, not April first.
Seriously, where has this gone wrong? the utilization rate of 16Bit ASNs should not be a measure for replenishing the 32 bit Pool.
It should never have been.
+1 - Håvard
Hello, A very disappointing side-effect. Is it possible to have IANA derogate to the rule ? It's like falling in a trap we dug ourselves... Hopefully, we did not make the same mistake for IPv4/v6 addresses ! Bertrand -----Message d'origine----- De : address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] De la part de Havard Eidnes Envoyé : jeudi 14 mars 2013 14:14 À : rg@teamix.de Cc : address-policy-wg@ripe.net Objet : Re: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished
Under this policy, we need to demonstrate 80% usage of "the previously received ASN block" (which includes both 16-bit and 32-bit ASNs we received from IANA on 3 March 2012) to replenish our ASN pool. We are expecting to reach this usage rate within six to eight months.
Mh, not April first.
Seriously, where has this gone wrong? the utilization rate of 16Bit ASNs should not be a measure for replenishing the 32 bit Pool.
It should never have been.
+1 - Håvard
A very disappointing side-effect. Is it possible to have IANA derogate to
Hi, Bertrand MAUJEAN wrote: [...] the rule In performing the IANA Functions, ICANN has committed to act in-line with the policies developed by the policy developing communities, as documented in the ASO MoU (http://archive.icann.org/en/aso/aso-mou-29oct04.htm). Policy can be reviewed and revised when areas for improvement are identified. In the case of AS Number allocations, this has already happened with the replacement of the July 2008 policy (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-31jul08-en.htm) with the current September 2010 policy (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-21sep10-en.htm). The 2010 IANA Policy for Allocation of ASN Blocks to Regional Internet Registries creates a deterministic formula. ICANN performs a daily policy analysis based on the data provided by the RIRs on their FTP sites. The analysis for the RIPE NCC is published at: http://stats.research.icann.org/rir/RIPE/ASN/ Kind regards, Leo Vegoda Internet Corporation for Assigned Names & Numbers
Hi, On Mon, Mar 18, 2013 at 03:58:38PM -0700, Leo Vegoda wrote:
(http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-21sep10-en.htm).
*sigh* Going back, I can see that this was a global policy proposal that came from the RIRs itself (2007-04 in RIPE land), and I can only lament the lack of foresight - on the side of the proposers, and on the side of the responsible AP WG chair (me). http://www.ripe.net/ripe/policies/proposals/2007-04 Allocating 32bit(-only) ASNs in chunks of 1024 and for a time period of 12 months is just needless overhead - it made sense for 16bit ASNs which are quite obviously limited, but for 32bit ASNs, just allocating "enough" (like "all of AS3.* to RIPE NCC") would have been much more wise... OTOH, judging from the successful deployment of a good number of 32bit ASNs in RIPE land, I think we can state that using up the remaining 16bit ASNs now (at least those in the NCC pool) will not "needlessly burn up a valuable resource" - and I assume that IANA will replenish RIPE NCC's pool with a useful mixture of 32bit-only and 16bit chunks... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Tue, 19 Mar 2013, Gert Doering wrote:
OTOH, judging from the successful deployment of a good number of 32bit ASNs in RIPE land, I think we can state that using up the remaining 16bit ASNs now (at least those in the NCC pool) will not "needlessly burn up a valuable resource" - and I assume that IANA will replenish RIPE NCC's pool with a useful mixture of 32bit-only and 16bit chunks...
I would support any proposal for policy change to hand out 32 bit ASNs in larger chunks going forward, like 16384 at a time or even higher numbers. It would mean less work for people maintaining programs such as "whois - client for the whois directory service" because any range would last longer. I believe 32bit-ASNs should be handed out in 3-5 year forecasted growth. Doing small chunks just seems like needless overhead. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, On Tue, Mar 19, 2013 at 09:55:22AM +0100, Mikael Abrahamsson wrote:
I would support any proposal for policy change to hand out 32 bit ASNs in larger chunks going forward, like 16384 at a time or even higher numbers. It would mean less work for people maintaining programs such as "whois - client for the whois directory service" because any range would last longer. I believe 32bit-ASNs should be handed out in 3-5 year forecasted growth.
Doing small chunks just seems like needless overhead.
I'm not sure it's actually worth it - a global policy proposal is LOTS of work, and need to gain consensus in all the RIRs before it can go into effect. From the last Global Policy interactions with ARIN, most likely their lawyers will see some issue, change some wording, and break the whole thing right away - but even if they would follow common sense this time, it's still a lot of work (someone has to present to all 5 communities, lead the discussions, etc). IANA is free to chop up the ASN space in a reasonable way, so that the RIPE NCC would always receive ASN blocks from "AS3.*" (using the old asdot notation because it nicely reflects the 16+16 boundary) - and I think that RIPE DB maintenance can - and should - be automated for "oh, new chunk of ASNs" well enough so that it's not actually that much work. I still think what we have is reflecting strongly on the "conservation (and bureacratic processes!) above all else!!!" mentality IPv4 and 16bit ASNs brought upon us, but actually changing this particular aspect might not be worth the effort. That said, I won't stand in the way if someone wants to tackle this (and will be happy to help), of course. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Mar 19, 2013, at 5:05 AM, Gert Doering <gert@Space.Net> wrote:
I'm not sure it's actually worth it - a global policy proposal is LOTS of work, and need to gain consensus in all the RIRs before it can go into effect. From the last Global Policy interactions with ARIN, most likely their lawyers will see some issue, change some wording, and break the whole thing right away - but even if they would follow common sense this time, it's still a lot of work (someone has to present to all 5 communities, lead the discussions, etc).
Just to keep the discussion reality-based... The last "Global Policy for Allocation of ASN Blocks to the RIRs" actually went through the ARIN region in a prompt and straightforward fashion: - Formal introduction on PPML on 31 August 2009 - AC recommened Board adopt - 24 November 2009 - Adopted by the ARIN Board - 13 January 2010 Furthermore, the staff assessment indicated "Counsel does not see any material legal issues related to this policy." <https://www.arin.net/policy/proposals/2009_6.html> None of this is a predicator of how a revision to the Global ASN allocation policy would proceed, but in terms of Global Policy, it's likely the easiest one to change in short order. The real difficulty I see here is getting the community to actually converge on how they want these 16- and 32- bit ASN pools managed, and the process is completely secondary to the matter... FYI, /John John Curran President and CEO ARIN
(http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-21sep10-en.htm). *sigh*
we have rules, not common sense i am sure we can exchange 42 more messages, three policy proposals, spend time in dublin, ... </dripping sarcasm> randy
participants (9)
-
Andrew de la Haye -
Bertrand MAUJEAN -
Gert Doering -
Havard Eidnes -
John Curran -
Leo Vegoda -
Mikael Abrahamsson -
Randy Bush -
Rico Gloeckner