Search RPD Archives
[rpd] AFPUB-2014-GEN-004
Mwendwa Kivuva
Kivuva at transworldafrica.com
Mon Jun 8 18:02:24 UTC 2015
I support the proposal too. It got consensus from the floor to be adopted
after the changes.
Looking forward to hearing from Barry and Seun.
Regards
On Jun 8, 2015 7:26 PM, "Mark Elkins" <mje at posix.co.za> wrote:
> I also support the proposal as redrafted.
>
> On Mon, 2015-06-08 at 10:14 +0300, Barrack Otieno 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
>
> --
> Mark James ELKINS - Posix Systems - (South) Africa
> mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
> _______________________________________________
> 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/20150608/4d207ac9/attachment.html>
More information about the RPD
mailing list