[rpd] proposed policy: reservation of resources for IXPs

Thu Oct 30 17:59:26 UTC 2014

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