[105830] in North American Network Operators' Group
RE: Replacement for Avaya CNA/RouteScience
daemon@ATHENA.MIT.EDU (Eric Van Tol)
Thu Jul 3 16:52:29 2008
From: Eric Van Tol <eric@atlantech.net>
To: 'Christian Koch' <christian@broknrobot.com>, "Robert E. Seastrom"
<rs@seastrom.com>
Date: Thu, 3 Jul 2008 16:51:52 -0400
In-Reply-To: <c93a55220807031138u6a63b07fjccb7da8cee882953@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
>From: Christian Koch [mailto:christian@broknrobot.com]
>Sent: Thursday, July 03, 2008 2:39 PM
>To: Robert E. Seastrom
>Cc: Eric Van Tol; nanog@nanog.org
>Subject: Re: Replacement for Avaya CNA/RouteScience
>
>agreed. i see the most benefit from these boxes geared towards networks >w=
ith critical apps that are latency intensive and more than a handful of >tr=
ansit providers than i do for a smaller provider..
Two questions:
First, what would you characterize as a "smaller provider"? One that has o=
nly one or two transits? If that's the case, then yes, I would definitely =
agree with you. However, once you go beyond just a few transits and peers,=
choosing which one to use for an unhealthy destination becomes tedious if =
you're trying to do it all manually. That said, I believe there is a stopp=
ing point at which the size of the network outgrows the need for such a dev=
ice.
Second, can you provide an example of a network where users don't care abou=
t latency? I can't say that I've worked on tons of networks, but if "the i=
nternet is slow", and even though our customers may not be using the latest=
in realtime streaming media protocols and apps, they notice.
>depending on how many upstreams you're juggling, its not that hard to >cre=
ate some traffic engineering policies that can easily be modified, >(whethe=
r by hand or you use a script with a front end that can push the >changes f=
or you) in order to re-route traffic in the event of issues with >an SP net=
work in your end to end path..
It *is* relatively simple to make routing changes manually, but wouldn't yo=
u agree that human error is the cause of most outages? Even the most skill=
ed engineers/techs have days where their fingers are larger than normal. T=
hese devices, at least the one we use, makes no changes to router configura=
tions.
>personally i think manual traffic engineering and re-routing is one of >th=
e more fun parts of engineering..
>
>
>-christian
Yes, as long as the problem is interesting. Manually changing localpref on=
a route because of packet loss in someone else's network, several times pe=
r week, is not interesting to me or my staff. Nor is checking every transi=
t link several times a day to make sure that we're not going over a commit =
when other transits have plenty of bandwidth to spare.
In my opinion, most of the value of these types of appliances is to help id=
entify problem areas outside of your network, before end users notice them.=
I know firsthand that our route optimization appliance frees up my staff =
to work on other issues such as capacity planning, new service deployments,=
or discussing the latest MGS4 strategies. Well, hopefully not that last o=
ne.
-evt
