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

Wed Jan 6 11:34:42 EAT 2010

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 06_jan_09_aggr-week.png
Type: image/png
Size: 3870 bytes
Desc: not available
URL: <https://lists.kictanet.or.ke/pipermail/kictanet/attachments/20100106/ef1b1c32/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 06_jan_09_aggr-year.png
Type: image/png
Size: 5007 bytes
Desc: not available
URL: <https://lists.kictanet.or.ke/pipermail/kictanet/attachments/20100106/ef1b1c32/attachment-0001.png>