Re: US-Asia Peering

["Stephen J. Wilcox" <steve () telecomplete co uk>]

On 11 Jan 2003, Paul Vixie wrote:

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

which is also true for linx and manap, in that way its not massively different
from a normal connection and also meets the usual technical requirements of the
ixp requiring no special circumstances from the ixp

> 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

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

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

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

absolutely! which of course explains why all the neutral exchanges have small
coverage area - a couple of close sites inside a city. and some of the
commercial exchanges have gone beyond and offer long distance peerings as they
dont care if they compete, they may well welcome it.

Steve