Search RPD Archives
[rpd] proposed policy: reservation of resources for IXPs
Bill Woodcock
woody at pch.net
Fri Oct 31 00:07:30 UTC 2014
I support.
-Bill
> On Oct 31, 2014, at 5:07, "Frank Habicht" <geier at geier.ne.tz> wrote:
>
> 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
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
More information about the RPD
mailing list