RE: IGP metrics on WAN links

["Daniel Golding" <dgolding () sockeye com>]

I suspect the approach you take depends on how your network looks. If you
have many pipes of a variety of sizes, doing IGP metrics based on pipe size
makes a good deal of sense, then adding twists for things like ckt latency.
However, folks with uniform sized networks, and uniform traffic between
coasts probably tend to set IGP metrics for latency, with pipe size being
the exception that they bias for afterwards.

The latter is probably more prevelent in an established network, the former
in a network undergoing a large fiber build.

- Dan

> -----Original Message-----
> From: owner-nanog () merit edu [mailto:owner-nanog () merit edu]On Behalf Of
> Joe Abley
> Sent: Friday, July 19, 2002 4:25 PM
> To: Me
> Cc: Sush Bhattarai; nanog () merit edu; Tom Holbrook
> Subject: Re: IGP metrics on WAN links
>
>
>
> On Fri, Jul 19, 2002 at 02:11:29PM -0600, Me wrote:
> > I think you missed part of his comment:
> > " of course there are always some "twinking" done regularly to
> give higher
> > priorities to the higher bandwidth, link condition etc"
> >
> > so fiber mileage is just the base, with modifications to make it work
> > correctly, based on bandwidth, etc.
>
> Yeah, my (limited) experience is the opposite. At the previous large
> operator at which I had enable, the IGP metrics were chosen primarily
> according to circuit size, and were subsequently tweaked for other
> issues (such as circuit latency, or the requirement to balance cross-
> US traffic across non-parallel circuits).
>
> In my experience, congestion is a much more effecive killer of service
> than latency due to optical distance. Hence attracting traffic to
> circuits where there is more likely to be headroom seems a more
> reasonable first-order approach for choosing metrics.
>
> That experience is all in networks where intra-AS traffic engineering
> was done at the IP layer, however; in networks where there is a lower
> layer of soft traffic engineering maybe other approaches would be more
> appropriate.
>
>
> Joe