[kictanet] State Wrong on Internet Exchange Point , is it true

Wed Jan 6 16:58:17 EAT 2010

Thanks Michuki for pointing out this misunderstood issue.

Regards
Sammy

On 1/6/10 11:34 AM, "Michuki Mwangi" <michuki at swiftkenya.com> wrote:

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