...

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.

yes but to clarify as most exchanges enforce a single mac address per port and you dont want to bridge the two ixps you will have at least one L3 hop between the IXPs, which protects you against the nasties of large L2 topologies and L2 meltdowns

which all goes to why PAIX doesn't trunk its connections to packetexchange (or telseon or yipes or etc.) (or SIX or NYIIX or etc.)

...

2. laughability. noone who peers remotely in this way will qualify ...

thats odd, surely the main purpose of this requirement is to ensure that the peering is as cost neutral as possible, eg someone peering with Sprint at a single site exchanging global routes (own, customer) will clearly save the ISP money and cost sprint who now have to ship traffic to and from that site - a good case for not peering or peering only local routes. whether the mechanism by which the interconnect is enabled is long reach ethernet or sdh or whatever doesnt seem important to the peering policy

as i said previously: peering isn't about cost or technology. what the restrictive-peering network owners are looking for is "are you a peer in real life?" which translates loosely to "are you going to be able to sell to the same customers i do whether i peer with you or not?" one of the litmus tests is "backbone strength", where an L1 backbone is considered to be in a completely different strength class from an L2-L2.5-L3 backbone.