|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 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.
|