Re: AT&T NYC

["Stephen J. Wilcox" <steve () opaltelecom co uk>]

On Mon, 2 Sep 2002 bdragon () gweep net wrote:

> > > Has anybody mentioned the benefits of ISIS as an IGP to them.
> >
> > Link-state protocols are evil, and when they break, they *really* break.
> > I still do not see a compeling argument for not using BGP as your IGP.

Convergence time?

> > Alex
>
> iBGP is only one half of an IGP. It is the "where to go" half.
> You still need some other igp (isis, ospf, rip, static routes, etc) for
> the "how to get there" half.
>
> Most large providers carry next-hops (loopbacks, border /30 (or /31), etc)
> around in either isis or ospf, and carry the remainder in iBGP.
>
> The reason?
>
> With link-state, one interface flap can mean doing SPF on every route.
> If "every route" is only a couple hundred, rather than 100K, you fare

As you say disable synchronization and try and control the physical reach of
your igp by some mechanism.. areas, summaries, ASes etc

Steve

> better when circuits are flapping. At that point, comparing the precomputed
> metric amongst 100k routes is (imho) rather trivial, especially when
> "igp metric" is a few steps down the decision tree.
>
> In all practicality, you need to haul, at least, eBGP routes around in iBGP,
> you need some kind of other igp to jumpstart iBGP, and is advised that this
> other igp have some concept of metric or cost to be able to give BGP
> some hints. Whether you choose to make your non-BGP igp lean and mean
> (disabling synchronization, with the attendant caveats) or fat and happy
> (and suffer the consequences during repeated link state changes), is up
> to the reader, but you still really need two igps.