The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. Mike Bernico -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of vijay gill Sent: Tuesday, June 21, 2005 9:20 AM To: Dan Evans Cc: nanog@merit.edu Subject: Re: OSPF -vs- ISIS Dan Evans wrote:
All,
Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior.
Any insights or experiences that you can share would be most helpful.
Thanks,
Daniel Evans Alltel Communications
Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay
Thus spake "Mike Bernico" <mbernico@illinois.net>
The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain.
We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers.
This points to something that's really unrelated to the minor technical differences between the two protocols: how they're viewed by your vendor. One vendor in particular sees ISIS as "an ISP protocol" and OSPF as "an enterprise protocol". Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet. The difference in stability is less apparent today, but the mindset is still quite alive. That means ISIS gets "ISP" features faster, and the code still tends to be more solid than OSPF even though ISIS might now be getting changes more frequently than it did in the past. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Tue, Jun 21, 2005 at 11:50:59AM -0500, Stephen Sprunk wrote:
Thus spake "Mike Bernico" <mbernico@illinois.net>
The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain.
We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers.
This points to something that's really unrelated to the minor technical differences between the two protocols: how they're viewed by your vendor.
One vendor in particular sees ISIS as "an ISP protocol" and OSPF as "an enterprise protocol". Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet.
To that end, you also need to be aware that outside of the "major" vendors, most don't even know what ISIS is. So if you're trying to integrate other vendors' equipment into your network, you may have no choice but OSPF.
The difference in stability is less apparent today, but the mindset is still quite alive. That means ISIS gets "ISP" features faster, and the code still tends to be more solid than OSPF even though ISIS might now be getting changes more frequently than it did in the past.
Personally, I still favor ISIS in provider style networks, especially as they grow larger but with the passage of time, there really isn't a great deal of difference between ISIS level 2 only and one great big area 0 these days. (Personal experience has suggested to me that ISIS tends to handle that somewhat better but that doesn't say you won't be just as happy with OSPF.) So the long and short of it really boils down to your personal preference. --- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
"Wayne E. Bouchard" <web@typo.org> writes:
One vendor in particular sees ISIS as "an ISP protocol" and OSPF as "an enterprise protocol". Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet.
To that end, you also need to be aware that outside of the "major" vendors, most don't even know what ISIS is. So if you're trying to integrate other vendors' equipment into your network, you may have no choice but OSPF.
The other edge of that sword is that letting someone outside of the "major" vendors' OSPF (1) talk to your cloud qualifies as "risky behavior". ---rob (1) where "major vendors" means "widely deployed", not "widely deployed for money". the question is whether installing on your network is an unspoke part of their beta testing strategy.
participants (4)
-
Mike Bernico -
Robert E.Seastrom -
Stephen Sprunk -
Wayne E. Bouchard