<HTML>
<HEAD>
<TITLE>Re: [AfriNIC-rpd] Policy Proposal (Global): IANA Policy for Allocation of ASN Blocks to RIRs</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Some information on ASN allocations from AfriNIC:<BR>
<BR>
<B>32-bit:<BR>
---------<BR>
</B>Seven 32-bit ASNs have been issued since the policy was implemented in Q2 2007. The trend:<BR>
<BR>
2007 2008 2009<BR>
3 1 3<BR>
<BR>
<B>16-bit:<BR>
---------<BR>
</B>509 issued in the region in total.<BR>
<BR>
Regards,<BR>
<BR>
-Vincent<BR>
<B>PS: Information was received from AfriNIC Registration Service Manager.<BR>
</B><BR>
On 8/28/09 4:38 PM, "Philip Smith" <<a href="pfs@cisco.com">pfs@cisco.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Frank,<BR>
<BR>
Vendors who ship software supporting configuration of 4-byte ASNs in BGP<BR>
are listed at <a href="http://as4.cluepon.net">http://as4.cluepon.net</a> - I think you'll find that it is<BR>
quite extensive.<BR>
<BR>
The cynic might now say that the ISPs should be blamed for not upgrading<BR>
to software that allows them to fully support customers with 4-byte ASNs<BR>
(i.e. be able to implement routing policy). The realist would then point<BR>
out that this quite often involves hardware upgrades too. ;-)<BR>
<BR>
Whatever, I agree with you that this proposal is quite essential to<BR>
ensure that AfriNIC can still receive 2-byte ASNs from the IANA after<BR>
the end of this year.<BR>
<BR>
philip<BR>
--<BR>
<BR>
<BR>
<BR>
Frank Habicht said the following on 28/8/09 23:12 :<BR>
> I support the policy proposal.<BR>
> <BR>
> That is for very practical reasons. Adoption of 32-bit ASNs has just not<BR>
> taken place to a significant extend.<BR>
> <BR>
> In addition I wonder if some "blame" can be put on vendors of BGP<BR>
> speakers. I wonder if RIRs or NRO can somehow "motivate" vendors to<BR>
> actively support and encourage deployment of products (the right<BR>
> software should mostly do) to enable inter-operation with 32-bit ASNs,<BR>
> including direct peering with them. Like giving the upgraded software<BR>
> away for free (with easy process).<BR>
> <BR>
> Thanks,<BR>
> Frank<BR>
> <BR>
> <BR>
> <BR>
> <a href="vincent@kenic.or.ke">vincent@kenic.or.ke</a> wrote:<BR>
>> The AfriNIC PDP-MG received the following policy proposal from Andrew de<BR>
>> la Haye from the RIPE NCC region. The policy proposal is a prospective<BR>
>> global policy as it has already been submitted in all the other RIR's. In<BR>
>> accordance with the AfriNIC Policy Development Process, the proposal is<BR>
>> being posted to the AfriNIC Resource Policy Discuss (RPD) Mailing List.<BR>
>> The proposal will also be placed on the AfriNIC website as a policy<BR>
>> proposal under discussion.<BR>
>><BR>
>> In line with the AfriNIC PDP, the AfriNIC community is now invited to<BR>
>> review and discuss this policy.<BR>
>><BR>
>> The AfriNIC Policy Development Process can be found at:<BR>
>> <a href="http://www.afrinic.net/docs/policies/afpol-pdp200707.htm">http://www.afrinic.net/docs/policies/afpol-pdp200707.htm</a><BR>
>><BR>
>> AfriNIC Mailing Lists subscription information can be found at:<BR>
>> <a href="http://www.afrinic.net/mailinglist.htm">http://www.afrinic.net/mailinglist.htm</a><BR>
>><BR>
>> Regards,<BR>
>><BR>
>> Vincent Ngundi<BR>
>> Chair, PDP-MG<BR>
>><BR>
>> ############ IANA Policy for Allocation of ASN Blocks to RIRs ###########<BR>
>><BR>
>> Name: Andrew de la Haye (<a href="andrew@ripe.net">andrew@ripe.net</a>), Stacy Hughes<BR>
>> (<a href="ipgoddess.arin@gmail.com">ipgoddess.arin@gmail.com</a>)<BR>
>> Organisation:<BR>
>> Policy Affected: IANA Policy for Allocation of ASN Blocks to RIRs<BR>
>> (afpol-asn200708)<BR>
>> Date: 27 May 2009<BR>
>> Proposal: Internet Assigned Numbers Authority (IANA) Policy for<BR>
>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries (Global<BR>
>> Policy proposal)<BR>
>><BR>
>> Summary of proposal:<BR>
>><BR>
>> According to the current global policy (afpol-asn200708), IANA will cease<BR>
>> to make any distinction between 16-bit and 32-bit only ASN blocks by 31<BR>
>> December 2009, when making allocations to RIRs. This proposal is to extend<BR>
>> this date by one year, to 31 December 2010.<BR>
>><BR>
>><BR>
>> Policy text<BR>
>><BR>
>> Current Policy Text (in current afpol-asn200708):<BR>
>><BR>
>> 1. Allocation Principles<BR>
>><BR>
>> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the<BR>
>> term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009,<BR>
>> allocations of 2-byte only and 4-byte only ASN blocks will be made<BR>
>> separately and independent of each other. This means until 31 December<BR>
>> 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs<BR>
>> and one for 4-byte only ASNs from the IANA under this policy. After this<BR>
>> date, IANA and the RIRs will cease to make any distinction between 2-byte<BR>
>> only and 4-byte only ASNs, and will operate ASN allocations from an<BR>
>> undifferentiated 4-byte ASN allocation pool.<BR>
>><BR>
>> …<BR>
>><BR>
>> <a href="http://www.afrinic.net/docs/policies/afpol-asn200708.htm">http://www.afrinic.net/docs/policies/afpol-asn200708.htm</a><BR>
>><BR>
>><BR>
>> New Policy Text:<BR>
>><BR>
>> 1. Allocation Principles<BR>
>><BR>
>> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the<BR>
>> term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,<BR>
>> allocations of 16-bit and 32-bit only ASN blocks will be made separately<BR>
>> and independent of each other [1].<BR>
>><BR>
>> This means until 31 December 2010, RIRs can receive two separate ASN<BR>
>> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA<BR>
>> under this policy. After this date, IANA and the RIRs will cease to make<BR>
>> any distinction between 16-bit and 32-bit only ASNs, and will operate ASN<BR>
>> allocations from an undifferentiated 32-bit ASN allocation pool.<BR>
>><BR>
>> …<BR>
>><BR>
>> 1.<BR>
>> 16-bit ASNs are the AS Numbers in the range: 0 - 65535<BR>
>> 32-bit only ASNs are the AS Numbers in the range: 65536 - 4294967295<BR>
>> 32-bit ASNs are the AS Numbers in the range: 0 - 4294967295<BR>
>><BR>
>> Rationale:<BR>
>> a. Arguments supporting the proposal<BR>
>><BR>
>> Due to operational issues external to the IANA/RIR policy process, 32-bit<BR>
>> only ASNs are not being issued by the RIRs at the anticipated rate. As it<BR>
>> stands, RIRs will likely not be able to justify a new block of ASNs from<BR>
>> the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in<BR>
>> the RIR’s pool. This leaves available, essential 16-bit ASNs stranded in<BR>
>> the IANA free pool. This proposal seeks to remedy the potential problem<BR>
>> by extending the deadline for differentiation by one year.<BR>
>><BR>
>> With this proposal the policy will be aligned with the actual reality in<BR>
>> regards to 32-bit ASN deployment and usage.<BR>
>><BR>
>> b. Arguments opposing the proposal<BR>
>><BR>
>> Some may think that extending the previously set timeline can be perceived<BR>
>> as some discouragement for the deployment of 32-bit ASNs. One counter<BR>
>> argument to this is that RIRs and Internet community have some other<BR>
>> mechanisms and activities to raise awareness for 32-bit ASN pool (via<BR>
>> public presentations and trainings). These activities will continue while<BR>
>> 16-bit ASN blocks are still allocated to RIRs by the IANA as they are<BR>
>> available and they are needed.<BR>
>><BR>
>> #######################<BR>
>><BR>
>><BR>
>><BR>
>> _______________________________________________<BR>
>> rpd mailing list<BR>
>> <a href="rpd@afrinic.net">rpd@afrinic.net</a><BR>
>> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><BR>
> <BR>
> _______________________________________________<BR>
> rpd mailing list<BR>
> <a href="rpd@afrinic.net">rpd@afrinic.net</a><BR>
> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><BR>
> <BR>
<BR>
_______________________________________________<BR>
rpd mailing list<BR>
<a href="rpd@afrinic.net">rpd@afrinic.net</a><BR>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>