[afnog] Survey: Collecting African IXP Colocation Data for research purposes (Slight changes in the survey)

[Nishal Goburdhan]

On 01 Mar 2016, at 01:40, Roderick <roderick.fanou at imdea.org> wrote:
> Hi Nishal, 
> Sorry, I just saw the list of the members here: http://www.mixp.org/#members.
[..]
> Because I did not spotted the website and hence the list :( that’s why I put “if”. Sorry

it’s ok, nobody got hurt  :-)


>>> , I would not consider Mauritian IXP as an IXP (without even performing traceroutes and carrying an AS path analysis).
>>> - If  “3 peers" among which both ASes 23889 and 30999 are listed, then given the AS path above the Mauritian IXP is not working; since all networks should be peering with one another.
>> not all networks might agree :-)
> 
> We are not in this case neither.  But still if we had 3 peers at the exchange point, they should peer with one another. Each of them should have 2 peers. 
> A network that want to peer with only one AS is used to establish a private peering link. 

consider: 
A <—> B 
B <—> C 
some neutral place in the middle.

in this (academic) case, there is no A <—> C peering.  but B, might insist that it’s peer A or C, meet it *at* the IXP, and it might have sufficient leverage to enforce that.  in this case, B enjoys economies of scale from a single larger transmission link to the IXP;  A and C get peering with B, but might not have a transmission benefit.  



>>> - If more than 3 peers are listed to me, then this only traceroute is not sufficient to decide; since an ISP can decide to peer with some members and not with others.
>>> Please note that traceroutes should be performed in both directions and note that there are 30 ASNs in Mauritius (https://stat.ripe.net/MU#tabId=database).
> 
> MIXP can be classified in this case thanks to its 10 peers. As I say, the traceroute only allows me to deduce that Mauritius Telecom and EMTEL are not peering at MIXP. 

more correctly, the prefixes that you are are testing to/from, are not being exchanged over the MIXP.  it’s a subtle difference, but, since your paper is academic, you should note this subtlety..


> But I can not say that MIXP is not working: this requires that I launch traceroutes among all members. 

there’s live traffic flowing across it;  i would say that the IXP is working fine, although it may not be providing as much benefit as it *could* to the networks participating there.  extracting maximum benefit from the IXP is largely the responsibility of the active peering participants.  from my own experience, i can tell you that many operators in this region, are unaware of how to engage in, and maintain peering at IXPs, and see it simply as a “plug-in-and-forget-about-it” experience  :-(

—n.