>From: Christian Koch [mailto:[EMAIL PROTECTED] >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
