Theres an increasing number of "psuedo-wire" connections tho, you could regard
these L2 extensions an extension of the switch as a whole making it
international.
Thats not really applicable in my view, the psuedo-wire is no
different to a long fibre extension and they are only used to connect
specific parties not IXP's.
Regards,
Neil.
Sure, purpose is different but functionally the pseudowire is the same as the
exchange, a collection of L2 devices and either has the potential in the event
of a L2 issue (arp storm, STP) to affect the other in the absence f any L3
boundary. The fact that it only connects a single device is arbitrary.
In response to Randy and Bill(s), this seems to come down to a trade off of
commercial vs technical. A lot of us agree this is technically not the best way
and produces instabilities with the potential to take out major chunks of
internet but it is cheap and this means people will adopt this way of doing it,
unfortunately as this has now happened it means those opposed to the idea will
have to also consider this as an option if they are to compete.
The growing number of things in the Internet business which nowadays need to
more cheap and less technically sound is something I find disheartening.
Steve
I don't think it's fair to characterize it as a trend... I mean, ten
years ago, we were all (generalizing here) stupid enough to try these
tricks. Fortunately, smarter people have come along since, and learned
from our mistakes. There are also _vastly_ more people involved in the
industry now than then, so it comes as no surprise that there are still
some newbies trying this, despite all the lessons of the past. The good
news is that although they're a quantitatively growing group, they're a
shrinking _fraction_ of the whole. So that's evidence of some small
progress in the state of knowledge. Fight the law of conservation of
clue!
-Bill
Bill - the argument seems like Proof by Rigorous Assertion:
I know it is a bad idea.
I really really believe it is a bad idea.
My friends say it's a bad idea.
Not one that I know says it is a good idea.
Therefore, and I can't emphasize this enough, in conclusion, it is a bad idea.
If what you are saying is true, I'd really like to hear just a couple of insurmountable technical problems with WAN L2.5 infrastructure interconnecting IX switches. 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.
I can articulate a half dozen reasons why this is a good idea. Please share with us why this is a such a bad idea. If it has been tried before, it would be helpful to point to specific the case and why it failed, the technical failure scenario. I'd like to hear why/how it was worse by the distance between switches.
Bill
> > In response to Randy and Bill(s), this seems to come down to a
> trade off of
> > commercial vs technical. A lot of us agree this is technically not
> the best way
> > and produces instabilities with the potential to take out major
> chunks of
> > internet but it is cheap and this means people will adopt this way
> of doing it,
> > unfortunately as this has now happened it means those opposed to
> the idea will
> > have to also consider this as an option if they are to compete.
>
>I don't think it's fair to characterize it as a trend... I mean, ten
>years ago, we were all (generalizing here) stupid enough to try these
>tricks. Fortunately, smarter people have come along since, and learned
>from our mistakes. There are also _vastly_ more people involved in the
>industry now than then, so it comes as no surprise that there are still
>some newbies trying this, despite all the lessons of the past. The good
>news is that although they're a quantitatively growing group, they're a
>shrinking _fraction_ of the whole. So that's evidence of some small
>progress in the state of knowledge. Fight the law of conservation of
>clue!
>
> -BillBill - the argument seems like Proof by Rigorous Assertion:
I know it is a bad idea.
I really really believe it is a bad idea.
My friends say it's a bad idea.
Not one that I know says it is a good idea.
Therefore, and I can't emphasize this enough, in conclusion, it is a bad idea.
Well, my comments were opinions and "in my experience".. which is a perfectly
valid argument
If what you are saying is true, I'd really like to hear just a couple of
insurmountable technical problems with WAN L2.5 infrastructure
Maybe it works fine technically.. I can think of a number of examples where
companies have their IT done cheaply and it "works" .. then they call an expert
when at some point down the line theres a problem they cant explain!
interconnecting IX switches. 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.
No, this isnt what I'm talking about. I'm talking of IXs with third party MPLS
transport providers connecting delivering vlan to remote sites.
However in your example above I think you have a scenario that I dont think is
available but is certainly around as proposals. The problems with that are not
simple, they are the possibility of complication introduced by multiple parties
and of unexpected behaviour arising which in such a large system has the
potential to affect many customers of many suppliers.
Steve
If what you are saying is true, I'd really like to hear just a couple of
insurmountable technical problems with WAN L2.5 infrastructure
interconnecting IX switches.
stephen stuart already answered that.
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
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.
the nice marketing/political angle is, it's no different from telseon or
yipes except for the distances involved, and even that's a temporary artifact
as everybody continues to try to cover everybody else's territories and
learn to sing everybody else's songs.
i believe that bandx tried to do this also, but i don't know as many details.
I can articulate a half dozen reasons why this is a good idea. Please share
with us why this is a such a bad idea. If it has been tried before, it
would be helpful to point to specific the case and why it failed, the
technical failure scenario. I'd like to hear why/how it was worse by the
distance between switches.
terminologically speaking, the thing that caused the uproar here when you
brought up the topic was only partly technical. important issues, in no
particular order of importance, are:
1. neutrality. this is something more than one wide-area-ethernet provider
must be allowed to do within an IXP if that IXP wants to claim neutrality.
further, the IXP cannot contract with a WAN provider for the purpose of
interconnecting its own switches, or it becomes a competitor of this whole
class of customer. (as a purist, i would normally go further, and say that
to be neutral, an IXP cannot negotiate contracts on behalf of its customers,
nor resell any customer's service, but let's do that in a separate thread,
or better yet, let's just not do it again, the archives already have it all.)
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.
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.
> 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.
-Billinside 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
Bill,
If what you are saying is true, I'd really like to hear just a couple of insurmountable technical problems with WAN L2.5 infrastructure interconnecting IX switches. 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.I can articulate a half dozen reasons why this is a good idea. Please share with us why this is a such a bad idea. If it has been tried before, it would be helpful to point to specific the case and why it failed, the technical failure scenario. I'd like to hear why/how it was worse by the distance between switches.
How do you see the failed AMS-IX expansion fit into this?
My (very simplified) summary of what happened was that :
a) ISPs where worried of the stability of the exchange (if I remember correctly Jesper Skriver made a good mail on this)
b) The large operators saw that AMS-IX would be directly competing with them on transit and transport revenues and therefor in the end where not interested in AMS-IX.
Note that there still was many (mostly small) ISPs that where in favour of the expansion.
At the time of the origin of the discussion I was peering co-ordinator at KPNQwest, and would have pulled-out of AMS-IX if the plans (and KQ ..
) would have moved on.
Best regards,
- kurtis -
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) writes:
Bill,
How do you see the failed AMS-IX expansion fit into this?
My (very simplified) summary of what happened was that :
...
At the time of the origin of the discussion I was peering co-ordinator at
KPNQwest, and would have pulled-out of AMS-IX if the plans (and KQ..
would have moved on.
well of course i'm not bill, but (naturally) i will comment anyway. was
AMS-IX planning to expand beyond its original metro and bridge all the XP
switches together? if so then i understand exactly why KQ and other ISP's
would have pulled out of AMS-IX in protest (and in fear). however, if the
expansion was intra-metro, then i must be confused, because KQ's major
source of bandwidth revenue should have been inter-metro not intra-metro.
Was AMS-IX planning to expand beyond its original metro and bridge
> all the XP switches together?
Yep.
-Bill
How do you see the failed AMS-IX expansion fit into this?
My (very simplified) summary of what happened was that :
...
At the time of the origin of the discussion I was peering co-ordinator at
KPNQwest, and would have pulled-out of AMS-IX if the plans (and KQ..
would have moved on.well of course i'm not bill, but (naturally) i will comment anyway. was
AMS-IX planning to expand beyond its original metro and bridge all the XP
switches together? if so then i understand exactly why KQ and other ISP's
would have pulled out of AMS-IX in protest (and in fear). however, if the
expansion was intra-metro, then i must be confused, because KQ's major
source of bandwidth revenue should have been inter-metro not intra-metro.
They planed to interconnect other (well, one) other exchanges in NL.
Best regards,
- kurtis -