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

Fw : Re: [rpd] proposed policy: reservation of resources for IXPs

sylvain aboka baya abscoco2001 at yahoo.fr
Tue Dec 2 11:28:17 UTC 2014


Hi all, 
Dear Mukom,


--- En date de : Mar 2.12.14, Mukom Akong T. <mukom.tamon at gmail.com> a écrit :

> De: Mukom Akong T. <mukom.tamon at gmail.com>
> Objet: Re: [rpd] proposed policy: reservation of resources for IXPs
> À: "rpd" <rpd at afrinic.net>
> Cc: "Nishal Goburdhan" <nishal at ispa.org.za>
> Date: Mardi 2 décembre 2014, 10h28
> ****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!
> ******************************************************************************************************************
> 


Your proposal is very wise dear Mukom !


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

 I don't want to directly propose values for "NN" and "X" because I think that we can add something to upgrade this interesting proposal and better motivate a quick use of our ressources:

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

 When "at least X% of the reserved space has not been used", it "returned to the normal pool!"; then to be able/allowed to apply/request for another same kind of ressources, the concerned Organization (Network Operators, ISP, AfriNIC's Member, Others, ...) must wait [Y] years/months to submit that request.

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

Excuse me ;-) I have add a new unknown factor "Y" for which we have to also give/affect a value.

Best Regards,
--sb.


> 
> On Fri, Nov 7, 2014 at 7:48
> AM, Serge ILUNGA <sergekbk at yahoo.fr>
> wrote:
> ++1
> 
> Serge ILUNGA KABWIKASkype:
> sergekbkCell: +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
> -------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> -----La pièce jointe associée suit-----
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 




  Best Regards !                                                     
 
************************
Sylvain BAYA
 CCNA
cmNOG's Co-Founder & Coordinator
ISOC Cameroon Board's Member

 (+237) 77005341                              

PO Box 13107 YAOUNDE / CAMEROON
baya.sylvain [AT cmnog DOT cm] 
abscoco2001 [AT yahoo DOT fr]
http://www.cmnog.cm
http://www.isoc.cm
http://www.internetsociety.org
************************
" 1   J’ai attendu patiemment l’Éternel; et il s’est penché vers moi, et a entendu mon cri.
2   Il m’a fait monter hors du puits de la destruction, hors d’un bourbier fangeux; et il a mis mes pieds sur un roc, il a établi mes pas.
3   Et il a mis dans ma bouche un cantique nouveau, la louange de notre Dieu. Plusieurs le verront, et craindront, et se confieront en l’Éternel. " (Psaumes 40 : 1- 2, 3)








More information about the RPD mailing list