US-Asia Peering

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