RE: Replacement for Avaya CNA/RouteScience

[Eric Van Tol <eric () atlantech net>]

> 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 >with critical apps that are latency intensive 
> and more than a handful of >transit providers than i do for a smaller provider..

Two questions:

First, what would you characterize as a "smaller provider"?  One that has only 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 stopping point at which the size of the network outgrows the need for such a device.

Second, can you provide an example of a network where users don't care about latency?  I can't say that I've worked on 
tons of networks, but if "the internet 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 >create some traffic engineering policies that 
> can easily be modified, >(whether by hand or you use a script with a front end that can push the >changes for you) in 
> order to re-route traffic in the event of issues with >an SP network in your end to end path..

It *is* relatively simple to make routing changes manually, but wouldn't you agree that human error is the cause of 
most outages?  Even the most skilled engineers/techs have days where their fingers are larger than normal.  These 
devices, at least the one we use, makes no changes to router configurations.

> personally i think manual traffic engineering and re-routing is one of >the 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 per week, is not interesting to me or my staff.  Nor is checking every transit 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 identify 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 one.

-evt