Thanks Michuki for pointing out this misunderstood issue. Regards Sammy On 1/6/10 11:34 AM, "Michuki Mwangi" <michuki@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@lists.kictanet.or.ke http://lists.kictanet.or.ke/mailman/listinfo/kictanet
This message was sent to: sammy@opensystems.co.ke Unsubscribe or change your options at http://lists.kictanet.or.ke/mailman/options/kictanet/sammy%40opensystems.co....