<p dir="ltr">I support the proposal too. It got consensus from the floor to be adopted after the changes.</p>
<p dir="ltr">Looking forward to hearing from Barry and Seun.</p>
<p dir="ltr">Regards </p>
<div class="gmail_quote">On Jun 8, 2015 7:26 PM, "Mark Elkins" <<a href="mailto:mje@posix.co.za">mje@posix.co.za</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also support the proposal as redrafted.<br>
<br>
On Mon, 2015-06-08 at 10:14 +0300, Barrack Otieno wrote:<br>
> I support the proposal<br>
><br>
> On Jun 8, 2015 9:38 AM, "Abibu Ntahigiye" <<a href="mailto:abibu@tznic.or.tz">abibu@tznic.or.tz</a>> wrote:<br>
>         I do support the proposal as well.<br>
>         -------------------------------------------------------------------------------------<br>
>         Eng. Abibu R. Ntahigiye; Manager, tzNIC;  +255 784 279 511<br>
><br>
>         On Jun 7, 2015, at 9:26 PM, Joe Kimaili wrote:<br>
><br>
>         > I support this proposal<br>
>         ><br>
>         > On Fri, Jun 5, 2015 at 5:15 PM, Frank Habicht<br>
>         > <<a href="mailto:geier@geier.ne.tz">geier@geier.ne.tz</a>> wrote:<br>
>         >         Hello colleagues,<br>
>         ><br>
>         >         We, the co-authors, hereby submit an update to<br>
>         >         AFPUB-2014-GEN-004<br>
>         >         incorporating the few editorial changes as agreed in<br>
>         >         the AfriNIC<br>
>         >         Public Policy Discussion and which were<br>
>         >         pre-condition to the consensus call.<br>
>         ><br>
>         >         The test follows below.<br>
>         ><br>
>         >         Regards,<br>
>         >         Nishal Goburdhan<br>
>         >         Michuki Mwangi<br>
>         >         Frank Habicht<br>
>         ><br>
>         ><br>
>         >         Details<br>
>         >         Ref. Name: AFPUB-2014-GEN-004-DRAFT-03<br>
>         >         Status: Last Call<br>
>         >         Date: 03 June 2015<br>
>         >         Author(s):<br>
>         >         Frank Habicht, Tanzania Internet Exchange, Michuki<br>
>         >         Mwangi, Internet<br>
>         >         Society/KIXP, Nishal Goburdhan, Packet Clearing<br>
>         >         House/JINX<br>
>         ><br>
>         >         1. Summary of the problem being addressed by this<br>
>         >         proposal<br>
>         ><br>
>         >         AFRINIC has an existing policy to make IPv4<br>
>         >         assignments to Critical<br>
>         >         Infrastructure, but not one to specifically reserve<br>
>         >         Internet Number<br>
>         >         Reources space for IXPs. As a result, it is<br>
>         >         anticipated that the<br>
>         >         exhaustion of these resources could make it<br>
>         >         difficult, if not impossible<br>
>         >         for IXPs to get sufficient resources to grow.<br>
>         ><br>
>         >         2. Summary of how this proposal addresses the<br>
>         >         problem<br>
>         ><br>
>         >         This policy requests AFRINIC to reserve, and publish<br>
>         >         IPv4 resources, and<br>
>         >         ASNs for use by IXPs only.<br>
>         ><br>
>         >         3.0 Proposal<br>
>         ><br>
>         >         3.1 Introduction<br>
>         ><br>
>         >         It is widely considered that Internet Exchange<br>
>         >         Points (IXPs) are one of<br>
>         >         the critical elements needed for Internet economies<br>
>         >         to develop. Africa<br>
>         >         is still in the process of developing these, and is,<br>
>         >         at the same time,<br>
>         >         faced with the imminent exhaustion of its IPv4<br>
>         >         resources.<br>
>         ><br>
>         >         Not having IPv4 addresses to grow, or start, new<br>
>         >         IXPs would create<br>
>         >         unnecessary and unneeded routing complexity for<br>
>         >         Internet connected<br>
>         >         networks, looking to peer at IXPs to further their<br>
>         >         network scope.<br>
>         ><br>
>         >         AFRINIC already has an existing policy to make<br>
>         >         allocations to IXPs [1],<br>
>         >         but that policy does not specifically reserve IPV4<br>
>         >         space to ensure that<br>
>         >         there will be such, for future IXPs to grow and<br>
>         >         develop.  Additionally,<br>
>         >         this policy reserves a set of ASNs between 0 - 65535<br>
>         >         for use by IXPs,<br>
>         >         for IXP BGP Route Servers.<br>
>         ><br>
>         >         3.2 Distinction between IXP peering and management<br>
>         >         networks<br>
>         ><br>
>         >         We distinguish between two kinds of IP number<br>
>         >         resources needed and used<br>
>         >         at IXPs.<br>
>         ><br>
>         >         An IXP peering LAN is the contiguous network address<br>
>         >         block that the IXP<br>
>         >         would use to assign unique IP addresses to each<br>
>         >         peering member, for each<br>
>         >         peering participant to exchange network traffic<br>
>         >         across the shared<br>
>         >         peering infrastructure. Best practice has the IXP<br>
>         >         peering LAN not being<br>
>         >         visible in a view of the global routing table, among<br>
>         >         other things to<br>
>         >         reduce the attack vectors for ISP border routers via<br>
>         >         the IXP.<br>
>         ><br>
>         >         >From a network identification, monitoring and<br>
>         >         analysis perspective, it<br>
>         >         is thus desirable, that the "peering LAN" space be<br>
>         >         provided from a<br>
>         >         contiguous block. The IXP management LAN is the<br>
>         >         management network that<br>
>         >         the IXP uses to provision services at the IXP, like<br>
>         >         monitoring,<br>
>         >         statistics, mail, ticket systems, provisioning of<br>
>         >         transit to DNS Roots,<br>
>         >         etc. Management networks, are meant to be reachable<br>
>         >         globally, for<br>
>         >         instance to publish data and allow remote access for<br>
>         >         common good network<br>
>         >         infrastructure (such as root and TLD DNS servers)<br>
>         >         and research projects.<br>
>         ><br>
>         >         3.3 BGP Route Servers use<br>
>         ><br>
>         >         Typically IXPs use BGP route servers to help manage<br>
>         >         peering sessions<br>
>         >         between different participants.  The route servers<br>
>         >         implement IXP routing<br>
>         >         policy in the form of BGP communities, typically in<br>
>         >         the form of A:B,<br>
>         >         where A,B represent A=IXP BGP route server and<br>
>         >         B=participant ASN.<br>
>         ><br>
>         >         Current BGP implementations utilise 6 bytes for the<br>
>         >         extended community<br>
>         >         attribute. Therefore, an IXP with a 4-byte ASN in<br>
>         >         use at its route<br>
>         >         server would not be able to successfully implement<br>
>         >         the A:B BGP community<br>
>         >         mapping, if an IXP participant has a 4-byte ASN.<br>
>         >         This situation is<br>
>         >         likely to be experienced by more IXPs, as additional<br>
>         >         4-byte ASNs are<br>
>         >         allocated through the current AFRINIC process.<br>
>         ><br>
>         >         If IXP route server communities include the IXP ASN<br>
>         >         and the peer's ASN<br>
>         >         (expected to be 4-byte), and a total of only 6 bytes<br>
>         >         are available, it<br>
>         >         follows that IXP route servers ASN could not be<br>
>         >         longer than occupying<br>
>         >         more than 2 bytes.<br>
>         ><br>
>         >         3.4 Proposal<br>
>         ><br>
>         >         To ensure that there are sufficient resources for<br>
>         >         IXPs to develop, this<br>
>         >         policy proposes that AFRINIC reserve IPv4 addresses<br>
>         >         for IXP peering LANs<br>
>         >         out of an address block marked particularly, and<br>
>         >         exclusively, for IXP<br>
>         >         peering LAN use.<br>
>         ><br>
>         >         Assignments for IXP peering LANs must be from one<br>
>         >         dedicated block,<br>
>         >         published as such by AFRINIC. The Peering LAN<br>
>         >         assignments for each IXP<br>
>         >         should ensure that the adjacent /24 IP block is<br>
>         >         reserved (based on the<br>
>         >         minimum end-user assignment policy size of /24) to<br>
>         >         support future growth<br>
>         >         of the IXP. This will enable an IXP to increase its<br>
>         >         peering LAN<br>
>         >         resources to /23 without having to renumber to a new<br>
>         >         contiguous IP block<br>
>         >         allocation.<br>
>         ><br>
>         >         Assignments for IXP management addresses should NOT<br>
>         >         be provided from the<br>
>         >         same block as the IXP peering LANs.<br>
>         ><br>
>         >         It is proposed that a /16 block be reserved for<br>
>         >         future requirements for<br>
>         >         IXP peering LANs in the AFRINIC service region, and<br>
>         >         that AFRINIC publish<br>
>         >         this block as such. In addition, the assignments for<br>
>         >         the IXP peering LAN<br>
>         >         should reserve the adjacent contiguous /24 IP block<br>
>         >         to the requesting<br>
>         >         IXP for future growth. These reservations shall be<br>
>         >         upheld until such a<br>
>         >         time that the available pool of the /16 can no<br>
>         >         longer allocate /23<br>
>         >         assignments. Thereafter, new requests may be<br>
>         >         assigned from the reserved<br>
>         >         space held for future IXP growth.<br>
>         ><br>
>         >         It is further proposed to reserve the equivalent of<br>
>         >         an additional /16<br>
>         >         block for IXP management prefixes, separate from the<br>
>         >         peering LANs.<br>
>         ><br>
>         >         It is proposed that AFRINIC reserves a block of ASNs<br>
>         >         between 0 - 65535<br>
>         >         for use in BGP route servers at IXPs in the AFRINIC<br>
>         >         service region. The<br>
>         >         number of ASNs to be reserved should be the larger<br>
>         >         of 114, or half of<br>
>         >         the remaining ASNs between 0 - 65535 within<br>
>         >         AFRINIC's block at the date<br>
>         >         of ratification of this policy.  AFRINIC will<br>
>         >         allocate these resources<br>
>         >         on a first come first served basis.<br>
>         ><br>
>         >         3.5 Evaluation criteria<br>
>         ><br>
>         >         This policy does not suggest new evaluation criteria<br>
>         >         for what determines<br>
>         >         a valid IXP.<br>
>         ><br>
>         >         4. Revision History<br>
>         ><br>
>         >         23 Oct 2014            AFPUB-2014-GEN-004-DRAFT-01<br>
>         >         posted on rpd list.<br>
>         >         05 Nov 2014            AFPUB-2014-GEN-004-DRAFT-02<br>
>         >         posted on rpd list.<br>
>         ><br>
>         >         References<br>
>         ><br>
>         >         [1] AFRINIC Policy for End User Assignments -<br>
>         >         AFPUB-2006-GEN-001,<br>
>         >         <a href="http://afrinic.net/en/library/policies/127-afpub-2006-gen-001" target="_blank">http://afrinic.net/en/library/policies/127-afpub-2006-gen-001</a><br>
>         >         Sections 5) and 6)<br>
>         >         _______________________________________________<br>
>         >         rpd mailing list<br>
>         >         <a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
>         >         <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
>         ><br>
>         ><br>
>         ><br>
>         ><br>
>         > --<br>
>         > Joe Kimaili<br>
>         > Ubuntunet Alliance<br>
>         > _______________________________________________<br>
>         > rpd mailing list<br>
>         > <a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
>         > <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
><br>
><br>
><br>
>         _______________________________________________<br>
>         rpd mailing list<br>
>         <a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
>         <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
><br>
> _______________________________________________<br>
> rpd mailing list<br>
> <a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
<br>
--<br>
Mark James ELKINS  -  Posix Systems - (South) Africa<br>
<a href="mailto:mje@posix.co.za">mje@posix.co.za</a>       Tel: +27.128070590  Cell: +27.826010496<br>
For fast, reliable, low cost Internet in ZA: <a href="https://ftth.posix.co.za" target="_blank">https://ftth.posix.co.za</a><br>
<br>_______________________________________________<br>
rpd mailing list<br>
<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br>
<br></blockquote></div>