Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] proposed policy: reservation of resources for IXPs

Serge ILUNGA sergekbk at yahoo.fr
Fri Nov 7 03:48:00 UTC 2014


++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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20141107/fd7288f8/attachment.html>


More information about the RPD mailing list