<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:16px"><div class="" id="yui_3_16_0_1_1415303649685_11902" dir="ltr" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 15.5555562973022px;"><br clear="none" class="" style="font-family: monospace; font-size: 13.3333339691162px;"><span class="" id="yui_3_16_0_1_1415303649685_11932" style="font-family: monospace; font-size: 13.3333339691162px;">I support the proposal with the extension of David Huberman.</span><br class="" style=""></div><div class="" id="yui_3_16_0_1_1415303649685_11902" dir="ltr" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 15.5555562973022px;"><span class="" style="font-family: monospace; font-size: 13.3333339691162px;">/Regards,</span></div><div class="" id="yui_3_16_0_1_1415303649685_11902" dir="ltr" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 15.5555562973022px;"><span class="" id="yui_3_16_0_1_1415303649685_11946" style="font-family: monospace; font-size: 13.3333339691162px;">/Janvier Ngnoulaye</span></div><br> <div style="font-family: times new roman, new york, times, serif; font-size: 16px;" id="yui_3_16_0_1_1415303649685_13329"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_1_1415303649685_13328"> <div dir="ltr" id="yui_3_16_0_1_1415303649685_13327"> <hr size="1"> <font size="2" face="Arial"> <b><span style="font-weight:bold;">De :</span></b> David Huberman <David.Huberman@microsoft.com><br> <b><span style="font-weight: bold;">À :</span></b> "rpd@afrinic.net" <rpd@afrinic.net> <br> <b><span style="font-weight: bold;">Envoyé le :</span></b> Jeudi 30 octobre 2014 18h59<br> <b><span style="font-weight: bold;">Objet :</span></b> RE: [rpd] proposed policy: reservation of resources for IXPs<br> </font> </div> <div class="y_msg_container"><br>Hello,<br><br>In regard to the proposed policy, "Resource Reservation for Internet Exchange Points", I have two comments:<br><br>1) I support the policy as written.<br><br>2) I ask the community for input on a separate policy proposal I would like to make, which is related.<br><br>One of the lessons we've learned over 20+ years of operating public IXes is that the worst thing that can happen to an IX is to grow so big that it outgrows its peering fabric /24. Renumbering a peering fabric is a nightmare scenario. It is preventable by having allocation policies which keep successful IXes in mind.<br><br>I propose, therefore, text which directs AFRINIC staff to:<br><br> - issue no less than a /24 to each IX peering fabric<br> AND<br> - either reserve the adjacent /24 so the /24 can grow to a /23 in the case where the IX is successful; or<br> - issue the /24s sparsely (using the bisection method) to ensure the most number of /24s can grow into /23s over time.<br><br>By carefully issuing /24s on /23 boundaries, it allows the (relatively few) IXes that will outgrow a /24 to easily move into a /23 with the same starting IP address, which makes it easy for the participants at the exchange.<br><br>Would this proposal have support?<br><br>Thanks and with regards,<br>David<br><br>David R Huberman<br>Microsoft Corporation<br>Principal, Global IP Addressing<br><br><br>> Subject: [rpd] proposed policy: reservation of resources for IXPs<br>> To: "rpd" <<a ymailto="mailto:rpd@afrinic.net" href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>><br>> Cc: "Nishal Goburdhan" <<a ymailto="mailto:nishal@ispa.org.za" href="mailto:nishal@ispa.org.za">nishal@ispa.org.za</a>><br>> Date: Wednesday, October 29, 2014, 5:01 PM<br>> <br>> Hello all,<br>> <br>> please find this proposed policy, which we (3 co-authors) have <br>> submitted to the pdpwg last week:<br>> <br>> Resource Reservation for Internet Exchange Points<br>> <br>> Author(s):<br>> a) Frank Habicht, Tanzania Internet Exchange<br>> b) Michuki Mwangi, Internet Society/KIXP<br>> c) Nishal Goburdhan, Packet Clearing House/JINX<br>> <br>> 1) Summary of the Problem being addressed by this proposal<br>> <br>> This policy reserves IPv4 and 2-byte ASNs resources for public <br>> Internet Exchange Points (IXPs) in the African region, ensuring that <br>> there would be discrete IPv4 resources to allow the establishment and <br>> growth of future IXPs.<br>> <br>> <br>> 2) Summary of How this Proposal Addresses the Problem<br>> <br>> This policy requests AfriNIC to reserve, and publish IPv4 resources, <br>> and 2-byte ASNs for use by IXPs only.<br>> <br>> <br>> 3) Proposal<br>> <br>> 3.1 Introduction<br>> <br>> It is widely considered that Internet Exchange Points (IXPs) are one <br>> of the critical elements needed for Internet economies to develop.<br>> Africa is still<br>> in the process of developing these, and is, at the same time, faced <br>> with the imminent exhaustion of its IPv4 resources. Not having<br>> IPv4 addresses to<br>> grow, or start new, IXPs would create unnecessary and unneeded <br>> routing complexity for Internet connected networks, looking to peer <br>> at IXPs to further their network scope. AfriNIC already has an <br>> existing policy to make allocations to IXPs [1], but that policy <br>> does not specifically reserve IPV4 space to ensure that there will <br>> be such, for future IXPs to grow and develop. Additionally, this <br>> policy reserves a set of 2-byte ASNs for use by IXPs for use at IXP <br>> BGP Route Servers.<br>> <br>> <br>> 3.2 Distinction between IXP peering and management networks<br>> <br>> We distinguish between two kinds of IP address resources needed and <br>> used at IXPs. An IXP peering LAN is the contiguous network address <br>> block that the IXP would use to assign unique IP addresses to each <br>> peering member, for each peering participant to exchange network <br>> traffic across the shared peering infrastructure. Best practice has <br>> the IXP peering LAN *not* being visible in a view of the global <br>> routing table, among other things to reduce the attack vectors for <br>> ISP border routers via the IXP.<br>> <br>> >From a network identification, monitoring and analysis perspective, <br>> it is thus desirable, that the "peering LAN" space be provided from <br>> a contiguous block. The IXP management LAN is the management network <br>> that the IXP uses to provision services at the IXP, like monitoring, <br>> statistics, mail, ticket systems, provisioning of transit to DNS <br>> Roots, etc.<br>> <br>> Management networks, are meant to be reachable globally, for <br>> instance to publish data and allow remote access for common good <br>> network infrastructure (such as root and TLD DNS servers) and <br>> research projects.<br>> <br>> <br>> 3.3 BGP Route Servers use<br>> <br>> Typically IXPs use BGP route servers to help manage peering sessions <br>> between different participants. The route servers implement IXP <br>> routing policy in the form of BGP communities, typically in the form <br>> of A:B, where A,B represent A=IXP BGP route server and B=participant <br>> ASN.<br>> Current BGP<br>> implementations utilise 6 bytes for the extended community attribute <br>> [RFC5668]. Therefore, an IXP with a 4-byte ASN in use at its route <br>> server would not be able to successfully implement the A:B BGP <br>> community mapping, if an IXP participant has a 4-byte ASN. This <br>> situation is likely to be experienced by more IXPs, as additional <br>> 4-byte ASNs are allocated through the current AfriNIC process.<br>> <br>> If, IXP route server communities include the IXP ASN and the peer's <br>> ASN (expected to be 4-byte), and a total of only 6 bytes are <br>> available, it follows that IXP route servers ASN could not be longer <br>> than a 2-byte ASN.<br>> <br>> <br>> 3.4 Proposal<br>> <br>> To ensure that there are sufficient resources for IXPs to develop, <br>> this policy proposes that AfriNIC reserve IPv4 addresses for IXP <br>> peering LANs out of an address block marked particularly, and <br>> exclusively, for IXP peering LAN use. Assignments for IXP peering <br>> LANs must be from one dedicated block, published as such by AfriNIC. <br>> Assignments for IXP management addresses should NOT be provided from <br>> the same block as the IXP peering LANs.<br>> <br>> It is proposed that a /16 block be reserved for future requirements <br>> for IXP peering LANs in the AfriNIC service region, and that AfriNIC <br>> publish this block as such.<br>> <br>> It is further proposed to reserve the equivalent of an additional <br>> /16 block for IXP management prefixes, separate from the peering <br>> LANs.<br>> It is proposed<br>> that AfriNIC reserves a block of 2-byte ASNs for use in BGP route <br>> servers at IXPs in the AfriNIC service region.<br>> <br>> The number of ASNs to be reserved should be the larger of 114, or <br>> half of the remaining 2-byte ASNs within AfriNIC's block at the date <br>> of ratification of this policy.<br>> <br>> AfriNIC will allocate these resources on a first come first served <br>> basis.<br>> <br>> <br>> 3.5 Evaluation criteria<br>> <br>> This policy does not suggest new evaluation criteria for what <br>> determines a valid IXP.<br>> <br>> <br>> 4.0 References<br>> <br>> [1] AfriNIC Policy for End User Assignments -<br>> AFPUB-2006-GEN-001<br>> <a href="http://afrinic.net/en/library/policies/127-afpub-2006-gen-001" target="_blank">http://afrinic.net/en/library/policies/127-afpub-2006-gen-001</a><br>> Sections 5)<br>> and 6)<br>> <br>> <br>> <br>> <br>> Note: proposal also available at<br>> <br>> <a href="http://www.afrinic.net/en/community/policy-development/policy-proposal" target="_blank">http://www.afrinic.net/en/community/policy-development/policy-proposal</a><br>> s/1231-resource-reservation-for-internet-exchange-points<br>> <br>> <br>> Regards,<br>> Frank<br>> _______________________________________________<br>> rpd mailing list<br>> <a ymailto="mailto:rpd@afrinic.net" href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>> <br><br><br>_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>_______________________________________________<br>rpd mailing list<br><a ymailto="mailto:rpd@afrinic.net" href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br><br></div> </div> </div> </div></body></html>