[rpd] proposed policy: reservation of resources for IXPs

Thu Oct 30 20:01:44 UTC 2014

Hi,

On 10/30/2014 8:59 PM, David Huberman 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.

Thank you.

> 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?

I think we could incorporate text towards this into the existing proposal,
after hearing more voices on this, but in general, the authors agree.

Cheers,
Frank

> 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
> 