US-Asia Peering

Sat Jan 11 22:47:01 UTC 2003

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