On Wed, Dec 12, 2001 at 09:34:09AM -0500, Robert E. Seastrom wrote:
>
> 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).
>
True, and there's not as much MPLS-TE stuff as there is BGP stuff.
Getting that documentation takes a mix of time and adapton, just like
anything else. In this way, it looks like multicast did(does?).
> 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...
>
MPLS-TE is good for two things:
1) deploying a full mesh between all routers in your core (or edge, if
you're masochistic/small enough) to get the benefits that traffic
engineering offers.
2) having around in case of unexpected congestion. Not short-term
(use stuff like WRED to handle that), and not long term (traffic
engineering, be it ATM or MPLS, is no substitute for a properly
designed physical layer), but medium-term adjustements. A new
Lewinsky report comes out, and for a few days or weeks your network
is unusually congested in places it's not normally.
These two are related, but they're different mindsets. I know people
at large networks who've done things each way.
> > > 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.
Agreed. The question you need to answer is whether you can save more
on router port and circuit costs (and associated things like rack
space, customer dissatisfaction due to congestion, etc) than it costs
you to use MPLS-TE. That point is different for everyone, and the
subjectivity of some of the costs (if you're predisposed to dislike
MPLS, your claimed operator cost will probably be higher than if
you're predisposed to like MPLS) means it's not strictly an
engineering/business case decision, althought it certainly should be.
>
> 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.
>
TE is all about controlling the paths to BGP next-hops. A real
confederation (meaning same IGP throughout the network) doesn't change
the next-hops, so there are still things that can be solved. A
network using multiple ASes and each AS with its own IGP can in fact
reduce the next-hop reachability problem to a set of smaller problems
which all are individually easy to solve. But then you have to futz
with BGP knobs to do load balancing within your network. This is
easily understood by more people because it's been out there longer,
but I don't think mpls-te is any more complex than BGP.
> 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.
Not everyone agrees with you - there are some big networks out there
that have mpls-te deployed and are happy with it. It's true that
twisting control-plane knobs can only squeeze so much more water from
the proverbial rock, but mpls-te certainly doesn't belong in the same
category as things which either don't exist or have zero demonstrable
benefit. See my point about predisposition earlier.
> 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.
What's the difference between having a dozen OC192s or a dozen OC3s or
a dozen DS3s? s/technology/budget/ above, and I think you and I are
very close to agreeing. Sure, you can get an OC48 instead of a
fistfull of OC3s, but only if you run from one router to another.
MPLS-TE lets you do all sorts of interesting things with your network
traffic. Whether you think they're nifty or snake oil,
euphemistically I think I can get away with "intersting". The things
it lets you do are the same things ATM and Frame Relay let you do -
follow paths that have a consumable resource (bandwidth) to get better
utilization out of your network.
This is stuff that ATM and FR networks have been doing for a long
time. No, I'm not claiming that MPLS-TE is reinventing FR or ATM, but
it lets you apply all the same principles but without as much
overhead. Surely you can agree that the principles behind traffic
engineering (not mpls-te, but the genric concept of resource-aware
trunk placement) are sound? Or do you think that all the atm and fr
routing folks are off their rocker, as well?
If you think that no packet/frame/otherwise oversubsribed network
needs to do anything other than IP does, then you certainly have to
admit there are lots of people who don't agree with you. If you
think that resource-aware trunk placement is in general a good thing,
how is it good if it's not MPLS but bad if it's MPLS?
eric
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:26 EDT