Eric Osborne <eosborne@cisco.com> writes:
> MPLS is like anything else - you should know how it works before you
> base a business around it. s/MPLS/BGP/ and your point is still true
> (although one doesn't convert to BGP, I suppose)
One can also figure out BGP with a pair of routers. Doesn't work so
well with MPLS. There's also a metric buttload of BGP101 papers out
there (consider the stuff Avi wrote, and there are others too).
The question is still the same: do you have the resources to be able
to keep your production network from becoming a greenfield network?
> > TE is no substitute for Quantity-of-Service. Given the finite number
> > of resources available in most small ISPs I've known, in your position
> > I would concentrate my efforts on upgrading my backbone and run good
> > 'ol HDLC on my point-to-point links.
>
> Absolutely. Don't run TE if you don't need it. But if you need what
> it can do, especially on a small enough network as to be easily mapped
> out on a piece of paper, there's nothing wrong with it.
If the network is that small, and you need what TE can do, you had
better be scrambling to upgrade your links, because if your sales
force is worth anything at all, by the time you get around to
implementing MPLS the traffic on your network will have grown to the
point that TE won't help you. The band in which TE does you any good
on a properly designed network is actually fairly narrow...
> > Can you believe the hype? I'll give you a hint: a huge proportion of
> > the people who are on the MPLS bandwagon right now are former ATM fans...
>
> I've never heard anyone argue against ATM by saying it's traffic
> engineering capabilities were bad. Sure, ATM has it downsides for
> running an all-IP network (*ahem* cell tax *ahem*), but if that's
> the major problem with ATM, then it doesn't apply to MPLS. YEs, you
> have a label stack that takes up extra space on the link, but you
> don't have a SAR overhead like ATM does, which is the major complaint
> I've heard about ATM.
Cell tax is not the major problem with ATM, it's only the one that is
most easily explained to people and thus the one that gets the most press.
One argument against any kind of virtual layer 2 network is that you
have O(n^2) endpoints to manage in the small network case, and
O(pop^2) endpoints to manage in the large network case (jiggle the
meaning of pop if you have a bloody-huge network). This is in
addition to your iBGP mesh. Is your engineering staff's time free?
Mine isn't.
A surprisingly large amount of TE can be accomplished with
confederated BGP. It simplifies the iBGP mesh _and_ allows some
control over where traffic goes on a pop-by-pop basis. And since it
all happens at the same layer, visibility for debugging is better.
IP doesn't need a second lieutenant. If the network is overloaded,
the solution is to upgrade the network, not to buy a perpetual motion
machine, magnetic mattress pad, copper bracelet, or MPLS. If the
network is so huge that it exceeds the ability of technology to keep
up (say you have a dozen coast-to-coast OC192s and you want to spread
your traffic between them), there might be a case for grody hacks
involving ATM or MPLS.
---Rob
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:57 EDT