If what you are saying is true, I'd really like to hear just a couple of insurmountable technical problems with WAN L2.5 infrastructure interconnecting IX switches.
stephen stuart already answered that.
For the sake of argument and to clarify the discussion (Paul) let's make a few assumptions:
1) We are talking about an operations model where IX switches are operated by a single company. 2) The IX switches are interconnected by MPLS by a transport provider offering that service. 3) An ISP on one switch creates a VLAN for peering with ISPs on any of the other switches. This ISP VLAN is only for peering with the ISP that created this VLAN. Since he is paying for the VLAN traffic he has this right. 4) The cost of transporting the traffic between the switches is bourne by a transport provider who in turn charges the ISP that created the VLAN in question.
packetexchange already does this between any number of IXP's. the only technical issue is whether to trunk the connection between packetexchange and the IXP (at PAIX we don't -- each such extended vlan gets its own port without vlan tagging and counts as a normal customer connection.) the nice economic angle in all this is that it's an IXP-independent service, so if someone at LINX-Docklands wanted to talk to someone at PAIX-NY, it'd work. the nice marketing/political angle is, it's no different from telseon or yipes except for the distances involved, and even that's a temporary artifact as everybody continues to try to cover everybody else's territories and learn to sing everybody else's songs. i believe that bandx tried to do this also, but i don't know as many details.
I can articulate a half dozen reasons why this is a good idea. Please share with us why this is a such a bad idea. If it has been tried before, it would be helpful to point to specific the case and why it failed, the technical failure scenario. I'd like to hear why/how it was worse by the distance between switches.
terminologically speaking, the thing that caused the uproar here when you brought up the topic was only partly technical. important issues, in no particular order of importance, are: 1. neutrality. this is something more than one wide-area-ethernet provider must be allowed to do within an IXP if that IXP wants to claim neutrality. further, the IXP cannot contract with a WAN provider for the purpose of interconnecting its own switches, or it becomes a competitor of this whole class of customer. (as a purist, i would normally go further, and say that to be neutral, an IXP cannot negotiate contracts on behalf of its customers, nor resell any customer's service, but let's do that in a separate thread, or better yet, let's just not do it again, the archives already have it all.) 2. laughability. noone who peers remotely in this way will qualify under any of the peering requirements i've seen on the topic of "must interconnect to us in N or more places M miles apart, and must have an OCxx backbone between those places." after some squabbling, an OCxx backbone that's on someone else's ATM or FR has been seen to qualify. but any claims about backbonitude that are based on a WAN-IP or WAN-Ether or WAN-MPLS have not been successful, and a lot of laughing was heard. 3. economics. because a lot of people didn't notice it the first time, here is another copy of woody's most excellent cutoff metrics argument: There's a threshold, defined by a step-function in the price-per-distance of layer-1 services. If you follow that step-function like a line on a topo map until it reconnects with itself, it forms a convex space. Interconnection of switch fabrics within that space is necessary to their success and long-term survival, whereas interconnection of switch fabrics across the border of that space is detrimental to their success and ultimately to their survival. -Bill inside that threshold, an IXP has to interconnect to remain relevant. outside that threshold, a neutral IXP cannot interconnect lest they compete with their customers. -- Paul Vixie