Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: AT&T NYC

  • From: bdragon
  • Date: Mon Sep 02 13:42:02 2002

> > 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.
> 
> 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
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.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.