[rpd] proposed policy: reservation of resources for IXPs

Thu Oct 30 22:13:33 UTC 2014

I generally support “sparse” allocation or more precisely allocation by bisection in all reserved special purpose blocks.

Owen

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