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

[Roderick]

On Feb 29, 2016, at 4:45 PM, Nishal Goburdhan <nishal at controlfreak.co.za> wrote:

> 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.  

Ok I see. This might happen. However, if it does A can infer that B is peering with C (C is not peering with A but is present at the IX). And similarly C can infer that A is peering with B.

>>>> - 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..

Yes, I agree. I can only infer from the traceroutes the view seen from the prefixes source and destination.  
 
Could you please tell me how often 2 ASes in the region exchange part of their network prefixes via an IXP although the rest is operational? 

>> 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.  

Sure. (PS: the *academic world* finds analyzing randomly collected measurements data more accurate than looking on the traffic graph published on the website ;) )

> 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  :-(

I hope this will change ;). 

Thanks, 

Roderick


> 
> —n.