<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi,<br><br>Thanks for the graph, since you are being transparent can you provide us with additional information that will give us some confidence that KIXP but meet the demands of keeping local traffic local.<br><br>- Maximum throughput achievable<br>- Services allowed to peer<br>- Capacity of each member to the exchange point<br>- Redundancy in the event of failure<br>- Burst capability.<br><br>Regards<br><br>PS.  On the GIXP it is quite justified let KIXP deal with the rest of us<br><br>Robert Yawe<br>
KAY System Technologies Ltd<br>
Phoenix House, 6th Floor<br>
P O Box 55806 Nairobi, 00200<br>
Kenya<br>
<br>
Tel: +254722511225, +254202010696<br><br>--- On <b>Wed, 6/1/10, Michuki Mwangi <i><michuki@swiftkenya.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Michuki Mwangi <michuki@swiftkenya.com><br>Subject: Re: [kictanet] State Wrong on Internet Exchange Point , is it true<br>To: "robert yawe" <robertyawe@yahoo.co.uk><br>Cc: "KICTAnet ICT Policy Discussions" <kictanet@lists.kictanet.or.ke><br>Date: Wednesday, 6 January, 2010, 8:34<br><br><div class="plainMail">Hi Robert,<br><br>Please see my comments inline. This time am wearing my KIXP CTO hat on :)<br><br>robert yawe wrote:<br>> Hi,<br>>  <br>> The GIXP is essential because KIXP is in principle a private entity of<br>> which membership is by invitation.<br><br>The above is not accurate - in anycase KIXP has tried to upload its<br>license requirement to connect only those operators
 licensed by CCK to<br>be Internet or Data service providers. Something in my humble opinion<br>that needs a review to allow any organization with content to be able to<br>connect i.e content providers etc.<br><br> GIXP is essential for security and<br>> also to improve on the governments internal traffic which they would not<br>> enjoy if using the KIXP which does not accomodate all providers.<br>>  <br><br>To start with KIXP provides a Layer 2 service like most other IXPs in<br>the world. Security in terms of access to the layer 2 infrastructure is<br>provided at all times. However our inability to connect everyone is a<br>limitation of the existing license requirement and not that of KIXP.<br><br>> KIXP mainly provides mail routing and the links from the various ISPs to<br>> the exchange point vary thus causing regular congestion which then falls<br>> you back to routing through the internet. <br><br>The specifics are very
 important here - we do not provide mail routing.<br>We provide a layer 2 infrastructure for interconnection. That means ISPs<br>come to KIXP instead of having direct links to every other ISP, but they<br>all have a single link to a single location. They use BGP protocol to<br>announce their own prefixes to all those at KIXP and receive the<br>prefixes (IP address blocks) of everyone else announcing at the<br>facility. IP addresses can originate and receive all known and unknown<br>internet services/protocols. Thus with KIXP providing a Switch (layer 2<br>service) we have no ability to filter based on protocol or other since<br>its a layer 2 service. Therefore protocol policies is not possible in a<br>layer 2 service.<br><br> If KIXP wants to disprove me<br>> let them give us access to the traffic graphs for the exchange point, a<br>> summary of the connected providers, protocols allowed and size of links<br>> to the exchange
 point.<br>>  <br>Please check on the kixp website for a listing of all this - its public<br>information www.kixp.or.ke under membership - we provide the data<br>available i.e Name, Status, ASN, EtherIP allocated to them at KIXP and<br>who their infrastructure provider is.<br><br>The aggregate traffic statistic is also available i have attached the<br>current weeks aggregate traffic and past 12 months as well.<br><br>For obvious reasons, i.e i doubt if any of our members would appreciate<br>us disclosing the capacity of their link to the KIXP is or what the<br>composition of their traffic is to a public mailing list. Am sure you<br>would equally not be pleased if your provider publicly published your<br>traffic composition on any public website.<br><br><br>I once again emphasize there's no protocol policing at the KIXP we<br>provide a layer 2 service and not a layer 3 service. We also dont<br>publish how much capacity they have but we do monitor
 individually.<br><br>> The IXP for Kenya needs to be owned and run by CCK and preferably placed<br>> in Mombasa at the entry/exit point of the fibre cables so as to reduce<br>> the inefficiencies of routing local traffic through expensive<br>> international gateways.<br>>  <br><br>If you carefully read my previous post, you will understand what a<br>market boundary is - you will further see why its economically viable to<br>have an IXP in Nairobi and another in Mombasa and any other market<br>boundary that can exist in the country/region. As to who runs the IXP<br>thats an open discussion and i placed some discussion points in the<br>previous email (commercial or non-profit).<br><br>For instance, KIXP was formed by the ISPs and as such is run by the ISP<br>association. If the KRA and others peer at the KIXP which is valuable to<br>them. One important aspect to have in mind is that for anyone to peer at<br>a facility, trust is a key
 concern - do your members trust you enough<br>that you are not going to be biased with the way you treat them. In any<br>case do they have a say on how the facility is run?. Please remember<br>that the ISP business is quite competitive hence trust issues are rife<br>and cannot be ignored.<br><br>> Carry out a trace between an ISP on SeaCom and another on TEAMS to see<br>> the routing that forces many of us to host overseas.<br>>  <br><br>If you have bandwidth limitations between one ISP to another not going<br>via KIXP, please check with that ISP, they have what it takes to be at<br>the KIXP (license and access to infrastructure) to have good speeds<br>available. For your information we monitor members links and advise them<br>when they fail, run close to the allowed threshold etc.<br><br>Here's my traceroute using Instaconnect/Igowireless to Jambo.co.ke which<br>is Jambonet. My ISP is on Seacom and i would presume TKL is on TEAMS.<br>The
 trace is via KIXP and the latencies are quite acceptable to me<br><br>Last login: Wed Jan  6 11:19:49 on ttys010<br>Mich:~ michuki$ traceroute -n www.jambo.co.ke<br>traceroute to www.jambo.co.ke (212.49.70.11), 64 hops max, 40 byte packets<br> 1  10.0.1.1  1.825 ms  1.670 ms  9.838 ms<br> 2  41.190.232.233  52.833 ms  84.094 ms  63.567 ms<br> 3  41.190.235.254  76.717 ms  59.312 ms  141.762 ms<br> 4  198.32.143.79  109.559 ms *  97.589 ms<br> 5  10.10.0.8  135.833 ms  44.089 ms  89.653 ms<br> 6  212.49.70.11  109.201 ms !<10>  101.042 ms !<10>  111.535 ms !<10><br>Mich:~ michuki$<br><br>I have similar traces to other networks which i can share - by the way i<br>live in a place called Kinoo on Naivasha Road, just before Kikuyu on<br>wimax solution. It works just fine for me. If you wish you can ask folks<br>on
 skunkworks to do their traces and submit their results, they will be<br>alot similar. The bottom line is, if an ISP has a limited capacity via<br>KIXP you need to push them to upgrade it. In some instances an ISP can<br>fail to announce all its prefixes at KIXP - we have no way of enforcing<br>this because its likely their peering policy or other decision. As such,<br>the impact of this will be felt across the entire network.<br><br>Hope that helps.<br><br>Regards,<br><br>Michuki.<br><br></div></blockquote></td></tr></table><br>