[rpd] AFPUB-2014-GEN-004

[McTim]

in favor as well.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel



On Mon, Jun 8, 2015 at 3:14 AM, Barrack Otieno <otieno.barrack at gmail.com> wrote:
> I support the proposal
>
> On Jun 8, 2015 9:38 AM, "Abibu Ntahigiye" <abibu at tznic.or.tz> wrote:
>>
>> I do support the proposal as well.
>>
>> -------------------------------------------------------------------------------------
>> Eng. Abibu R. Ntahigiye; Manager, tzNIC;  +255 784 279 511
>>
>> On Jun 7, 2015, at 9:26 PM, Joe Kimaili wrote:
>>
>> I support this proposal
>>
>> On Fri, Jun 5, 2015 at 5:15 PM, Frank Habicht <geier at geier.ne.tz> wrote:
>>>
>>> Hello colleagues,
>>>
>>> We, the co-authors, hereby submit an update to AFPUB-2014-GEN-004
>>> incorporating the few editorial changes as agreed in the AfriNIC
>>> Public Policy Discussion and which were pre-condition to the consensus
>>> call.
>>>
>>> The test follows below.
>>>
>>> Regards,
>>> Nishal Goburdhan
>>> Michuki Mwangi
>>> Frank Habicht
>>>
>>>
>>> Details
>>> Ref. Name: AFPUB-2014-GEN-004-DRAFT-03
>>> Status: Last Call
>>> Date: 03 June 2015
>>> Author(s):
>>> Frank Habicht, Tanzania Internet Exchange, Michuki Mwangi, Internet
>>> Society/KIXP, Nishal Goburdhan, Packet Clearing House/JINX
>>>
>>> 1. Summary of the problem being addressed by this proposal
>>>
>>> AFRINIC has an existing policy to make IPv4 assignments to Critical
>>> Infrastructure, but not one to specifically reserve Internet Number
>>> Reources space for IXPs. As a result, it is anticipated that the
>>> exhaustion of these resources could make it difficult, if not impossible
>>> for IXPs to get sufficient resources to grow.
>>>
>>> 2. Summary of how this proposal addresses the problem
>>>
>>> This policy requests AFRINIC to reserve, and publish IPv4 resources, and
>>> ASNs for use by IXPs only.
>>>
>>> 3.0 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 ASNs between 0 - 65535 for use by IXPs,
>>> for IXP BGP Route Servers.
>>>
>>> 3.2 Distinction between IXP peering and management networks
>>>
>>> We distinguish between two kinds of IP number 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. 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 occupying
>>> more than 2 bytes.
>>>
>>> 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. The Peering LAN assignments for each IXP
>>> should ensure that the adjacent /24 IP block is reserved (based on the
>>> minimum end-user assignment policy size of /24) to support future growth
>>> of the IXP. This will enable an IXP to increase its peering LAN
>>> resources to /23 without having to renumber to a new contiguous IP block
>>> allocation.
>>>
>>> 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. In addition, the assignments for the IXP peering LAN
>>> should reserve the adjacent contiguous /24 IP block to the requesting
>>> IXP for future growth. These reservations shall be upheld until such a
>>> time that the available pool of the /16 can no longer allocate /23
>>> assignments. Thereafter, new requests may be assigned from the reserved
>>> space held for future IXP growth.
>>>
>>> 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 ASNs between 0 - 65535
>>> 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 ASNs between 0 - 65535 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. Revision History
>>>
>>> 23 Oct 2014            AFPUB-2014-GEN-004-DRAFT-01 posted on rpd list.
>>> 05 Nov 2014            AFPUB-2014-GEN-004-DRAFT-02 posted on rpd list.
>>>
>>> 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)
>>> _______________________________________________
>>> rpd mailing list
>>> rpd at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>>
>>
>>
>> --
>> Joe Kimaili
>> Ubuntunet Alliance
>> _______________________________________________
>> 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
>