[rpd] proposed policy: reservation of resources for IXPs

Tue Dec 2 09:28:12 UTC 2014

****speaking without any hats and not taking any position*******

During the discussions about this proposal in Mauritius, I offered some
text that is aimed at addressing the concern that this proposal opens up
room for tying up resources in reservations that may not get used
eventually.

Here's my proposed text for the author's consideration

*********************************************************************************************************************

The authors understand that a policy doesn't exist in isolation from other
policies. Specifically the community has expressed fear that this policy
proposal could set a precedent where other groups (e.g. RENs, ccTLDs etc)
start making reservations that may end up not getting used.

To address these concerns, if by NN years from now, at least X% of the
reserved space has not been used, then this proposal becomes void and the
reserved space should be returned to the normal pool!

******************************************************************************************************************

I leave it to the authors and community to decide what reasonable values
for NN and X are, or even to subsitute better checks.

On Fri, Nov 7, 2014 at 7:48 AM, Serge ILUNGA <sergekbk at yahoo.fr> wrote:

> ++1
>
> Serge ILUNGA KABWIKA
> Skype: sergekbk
> Cell: +243814443160
>
> Le 6 nov. 2014 à 17:18, nico tshintu <bakajika at yahoo.fr> a écrit :
>
> Hello All,
>
> I support this proposal
>
>
> Nico TSHINTU BAKAJIKA
> Tél: 243 818149372
>
>
>   Le Mardi 4 novembre 2014 9h19, Fiona Asonga <tespok at tespok.co.ke> a
> écrit :
>
>
> Hallo All
>
> Based on our experience at KIXP and growth strategy moving forward. I
> support the proposal as it allows room for the IXPs to grow with minimum
> challenges on management of their allocation space.
>
> Kind regards
>
> Fiona Asonga
>
> Chief Executive Officer
>
> Telecommunications Service Providers Association of Kenya/ Kenya Internet
> Exchange Point
>
> Member Strategic Committee of the Africa Computer Emergency Response Team
>
>
>
>
> NRO Number Council http://www.nro.net/about/number-council.html
>
>
>
>
> ASO Address Council http://aso.icann.org/ac/
>
>
>
>
>
>
>
> 14 th Floor, Bruce House
>
> Standard Street
>
>
>
>
> Tel: +254 20 2245 036
>
> Cell: +254 721 713 504
>
> Website: www.tespok.or.ke
> ----- Original Message -----
> From: "Frank Habicht" <geier at geier.ne.tz>
> To: "rpd" <rpd at afrinic.net>
> Cc: "Nishal Goburdhan" <nishal at ispa.org.za>
> Sent: Wednesday, October 29, 2014 7:31:37 PM
> Subject: [rpd] proposed policy: reservation of resources for IXPs
>
> 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-proposals/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
>
>

-- 

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141202/556f4b97/attachment.html>