<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>----- Original Message ----- </FONT>
<DIV><FONT face=Courier size=2>From: Vadim Antonov <<A
href="mailto:avg@kotovnik.com">avg@kotovnik.com</A>></FONT></DIV>
<DIV><FONT face=Courier size=2>To: <<A
href="mailto:abender@tns-inc.com">abender@tns-inc.com</A>>; <<A
href="mailto:scharf@vix.com">scharf@vix.com</A>></FONT></DIV>
<DIV><FONT face=Courier size=2>Cc: <<A
href="mailto:nanog@merit.edu">nanog@merit.edu</A>></FONT></DIV>
<DIV><FONT face=Courier size=2>Sent: Tuesday, October 26, 1999 5:05
PM</FONT></DIV>
<DIV><FONT face=Courier size=2>Subject: Re: Traffic engineering
tools</FONT></DIV></DIV>
<DIV><FONT face=Courier size=2><BR> </DIV></FONT>
<DIV><FONT face=Courier size=2>> TE [snip] simply reallocates existing
resources differently.</FONT></DIV>
<DIV><FONT face=Courier size=2>></FONT></DIV>
<DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>In reading your mail, I'm reminded of one of my
favorite RFC's...</FONT></DIV>
<DIV><FONT face=Courier size=2>"The Twelve Networking Truths"</FONT></DIV>
<DIV><FONT face=Courier size=2></FONT> </DIV>
<DIV><FONT face=Courier size=2> (10) One size never fits
all.</FONT></DIV>
<DIV><BR><FONT face=Courier size=2>On the whole as a global solution, I would
agree with you that different is not necessarilly better, and sub-optimal
routing is not the best of solutions. There is an ISP we deal with who bounces
their traffic around the network until it finds an available exit. All the exit
points are nearly equally balanced, but the network as a whole is
slow.</FONT></DIV></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>In some specific cases however (mostly peering),
the peer's dynamic routing chooses what it believes to be the optimal exit path
by choosing 'closest gateway'/'nearest exit' routing. In these<FONT
face=Courier size=2> cases, sub-optimal utilization of your own
external connections by the peer creates severe congestion/loss.
</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>As an example I would present a peer with
multiple connections to your network in topologically distributed locations (ie.
opposite sides of your network). If the peer is utilizing one link in one
direction at 80% and the other two at 10%, you need to make some adjustments in
local pref, or redirect your outbound traffic destined for that peer (or his
downstreams) to the peer's underutilized path(s). Otherwise you're going to have
packets all over the floor at the link with 80% utilization. (!)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>TE is necessary more often than most would care
to admit, and occurs mostly at network borders, because none of the
carriers/providers like having to pay for additional external connectivity any
sooner than they absolutely _have_ to.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>If you are a large provider with a large number
of multiply-connected peers, traffic engineering (though rare) is a fact of
life. Of course from an implementation standpoint Truth number 6
says:</FONT></DIV>
<DIV><BR><FONT face=Courier size=2> (6) It is easier to move a
problem around (for example, by
moving<BR> the problem to a different
part of the overall network<BR>
architecture) than it is to solve it.<BR></FONT></DIV>
<DIV><FONT face=Courier size=2>..aww, heck, from any standpoint.</FONT></DIV>
<DIV><BR><FONT face=Courier size=2>> Note that customers do not generally
care about bandwidth. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>You didn't actually think I'd let this one slide,
did you?</FONT></DIV>
<DIV><FONT face=Courier size=2></FONT> </DIV>
<DIV><FONT face=Courier size=2>Next time _you_ can talk to the guy who's whining
that his 1.544Mb T1 (ESF, AMI, B8ZS & TCP/IP) is only getting ~1.4Mb
throughput (and of course, he's testing it with a web browser). After all,
he's paying for bandwidth, and he's the customer, and the customer is always
right. ;-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>> [the solution is] adequate provisioning
and capacity planning </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>Which of course is the BEST way to handle most
network problems, IF you have the money. ;-) Which brings me to the corollary to
fundamental truth number 7:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2> Good, Fast,
Cheap: Pick any two (you can't have all three).<BR></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>> I strongly suspect that is because there are
no real<BR>> measurable benefits - and that TE is being used mostly to cover
up<BR>> planning problems and as a short-term fix to idiocies at a<BR>>
transmission level.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>Of course there are benefits! They just don't
have anything to do with the network. Why spend $1,000's on new pipes/routers
when you can solve your problems for (almost) free by buying whatever will allow
you to tweak your routing and 'optimize your utilization of existing
resources'.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>(I cut and pasted that from a certain vendor's
marketing literature)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>Vendor Marketing plays on your Management's
fears. There's nothing that scares management more than justifying money
spent, especially money spent for 'unneeded' resources. The fact that that shiny
new gigabit pipe WILL eventually be fully utilized is immaterial. It's not being
used NOW.</FONT></DIV>
<DIV><FONT face=Courier size=2></FONT> </DIV>
<DIV><FONT face=Courier size=2>Small money is a small risk, and traffic
engineering alleviates the problem at the problem point sufficiently to make it
appear that it has gone away. It does this for minimal cost expenditure, which
is an 'optimal' solution where management is concerned.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>Which brings me to my own personal
addage:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2> You can troubleshoot layers 1-7,
</FONT></DIV>
<DIV><FONT face=Courier size=2> and work with layer 8
(users/engineers), </FONT></DIV>
<DIV><FONT face=Courier size=2> but there is absolutely nothing you
can do </FONT><FONT face=Courier size=2>with layer 9
(Management).</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>As for why anyone would use ATM
(B-ISDN):</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2> (11) Every old idea will be proposed
again with a different name and<BR> a
different presentation, regardless of whether it works.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Courier size=2>--JP</FONT></DIV>
<DIV><BR><FONT face=Courier
size=2>---------------------------------------------------------------</FONT></DIV>
<DIV><FONT face=Courier size=2>"No matter how hard you push and no matter what
the priority,<BR>you can't increase the speed of light." <BR>Fundamental Truth
#2 -- RFC 1925</FONT></DIV>
<DIV><FONT face=Courier
size=2>---------------------------------------------------------------</FONT></DIV></BODY></HTML>