Search RPD Archives
[rpd] proposed policy: reservation of resources for IXPs
jnoulaye at yahoo.fr
jnoulaye at yahoo.fr
Thu Nov 6 21:32:31 UTC 2014
I support the proposal with the extension of David Huberman.
/Regards,/Janvier Ngnoulaye
De : David Huberman <David.Huberman at microsoft.com>
À : "rpd at afrinic.net" <rpd at afrinic.net>
Envoyé le : Jeudi 30 octobre 2014 18h59
Objet : RE: [rpd] proposed policy: reservation of resources for IXPs
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141106/0884e4ab/attachment.html>
More information about the RPD
mailing list