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

[rpd] AFPUB-2014-GEN-004

Mark Elkins mje at posix.co.za
Mon Jun 8 16:26:04 UTC 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5810 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20150608/9e0e5feb/attachment.bin>


More information about the RPD mailing list