Replacement for Avaya CNA/RouteScience

Fri Jul 4 02:36:27 UTC 2008

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 at atlantech.net> wrote:

> >From: Christian Koch [mailto:christian at broknrobot.com]
> >Sent: Thursday, July 03, 2008 2:39 PM
> >To: Robert E. Seastrom
> >Cc: Eric Van Tol; nanog at 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$