Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Michuki_afrinic_pdp-presentation-v3
Similar to Michuki_afrinic_pdp-presentation-v3 (20)
More from AFRINIC
More from AFRINIC (20)
Recently uploaded
Recently uploaded (20)
Michuki_afrinic_pdp-presentation-v3
- 2. This policy serves to reserve IPv4 and 2byte ASNs for Internet Exchange Point peering LANs.!
- 4. Reminder! • IXPs peering LANs are not advertised to the Internet, but still require unique address space.! • IXP BGP Route servers usually accept BGP communities for peers’ policy control in the form ASNx:ASNy where X=their ASN and y=peer ASN.!
- 6. Reminder ! • IETF BGP Protocol definitions allow 6 bytes for Extended Community usage! There is no running code that extends this, and drafts and been in discussion for many years with no results…! While ISPs are free to change their community values internal to their network, they cannot change the value of “y”.!
- 7. Feedback from last meeting! • “Use soft landing … “! This doesn’t reserve resources for (previously defined in the EU policy) CIR. A run on SL could starve future IXPs of their needed resources.!
- 8. Feedback (2)! • “This is a repeat of the EU policy ….”! It’s not. This is a reservation request. AfriNIC has not previously reserved specific address blocks for IXPs. ! This was attempted with 196.223.x but other non-IXP entities also have address space from this block.!
- 9. Feedback (3)! • What about NRENs, ccTLDs, … ?! We (the authors) do not currently operate any of these, and do not believe that these share the same requirements (see previous note about non-routability).! The requirement for ASNs is specific for IXP route servers. ! The PDP allows individuals with greater understanding of these to make their own policy request.! We intend to support them.!
- 10. Feedback (4)! • “…put in a return-by date…”! We (the authors) find this option interesting, but suggest that instead of getting bogged down by numbers and dates, that a generic repeal of this policy be done through the PDP, if it’s found to be non-effective.!
- 11. Feedback (5)! • “How will this effect AfriNIC’s ability to get more ASNs from the IANA?” ! We admit that we did not consider this, and it was not highlighted as a concern in the staff analysis. But, good news … ;-)!
- 12. " -------- Forwarded Message --------" Subject: [IANA #796319] clarification - global ASN policy" Date: Tue, 2 Dec 2014 00:23:35 +0000" From: Selina Harrington via RT <iana-questions@iana.org>" Reply-To: iana-questions@iana.org" To: geier@geier.ne.tz" " Dear Frank Habicht," " Thank you for contacting us about the global ASN policy. Our interpretation" is that when an AS Number is not available for assignment to a customer" because it is being reserved/quarantined, it is not “free”. Therefore, if" AFRINIC implements a policy that reserves ASNs for special purposes, those ASNs should not be counted as "free”." " If you have any additional questions, please let us know." " Kind regards," " Selina Harrington" IANA Request Specialist" ICANN"
- 13. …and some suggestions received! • New text explaining problem statement from Douglas O. (thanks!) Willing to incorporate as a minor editorial change.! • Proposing to incorporate right now and if agreed move forward including this change!
- 14. Editorial Change! • New problem statement:! • AFRINIC has an existing policy to make IPv4 assignments to Critical Infrastructure, but not one to specifically reserve IPv4 space for IXPs. As a result, it is anticipated that the exhaustion of IPv4 could cause a scarcity of resources that could make it difficult, if not impossible for IXPs to get sufficient IPv4 resources to grow.!