[51616] in North American Network Operators' Group
Re: AT&T NYC
daemon@ATHENA.MIT.EDU (Stephen J. Wilcox)
Mon Sep 2 14:02:16 2002
Date: Mon, 2 Sep 2002 19:01:21 +0100 (BST)
From: "Stephen J. Wilcox" <steve@opaltelecom.co.uk>
To: bdragon@gweep.net
Cc: alex@yuriev.com, nanog@merit.edu
In-Reply-To: <20020902174004.6478.qmail@sidehack.sat.gweep.net>
Errors-To: owner-nanog-outgoing@merit.edu
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.
>
>
