imo, no more than 3-4 transit providers and maybe a presence at 1 or 2 ixp's with x amount of peer's would be small im not saying customers won't/don't care about latency, its just not difficult to route around the problematic nodes (unless SP A/B/C gets to it first and band aid the issue until resolution), maybe i just don't see enough issues to even recognize the problem? agreed, human error is a big cause of a lot of issues. well there are plenty of ways to manipulate traffic other than local_pref, that is why i find it interesting, you have options. i don't understand what the difficulty is in monitoring your bandwidth and understanding your traffic patterns, if this is done properly, you can plan capacity and execute your routing policies for optimal performance, and not have to re-route/re-engineer traffic so often. does your traffic fluctuate that much that you cant get a good grasp on what you're pushing, from who, and when? i definitely see value in appliances like the fcp and route science box, i just think for a smaller provider it may not be necessary - or maybe i have it backwards,and it is a better solution for a smaller provider so they don't have to waste money on highly skilled engineers? maybe i am just thinking "inside" the box at the moment, from an engineers view..if so my apologies for steering off course -christian On Thu, Jul 3, 2008 at 4:51 PM, Eric Van Tol <eric@atlantech.net> wrote:
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
-- ^christian$