Hey all,
Is there any reason to run IS-IS over OSPF in the SP core? Currently, we
are running IS-IS but we are redesigning our core and now would be a good
time to switch. I would like to switch to OSPF, mostly because of
familiarity with OSPF over IS-IS.
What does everyone think?
Well up until not too long ago, to support IPv6 you would run OSPFv3 and for IPv4 you would run OSPFv2, making IS-IS more attractive, but that is no longer the case with support for IPv4 NLRI in OSPFv3.
The only reason in my opinion to run IS-IS rather than OSPF today is due to the fact that IS-IS is decoupled from IP making it less vulnerable to attacks.
Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or
OSPFv3 from another protocol is still migrating to a new protocol
and b) even in the case of migrating to OSPFv3, there are fairly
significant changes in behavior from OSPFv2 to be aware of (most
notably
authentication, but that's fodder for another conversation).
-Tony
Having run both on some good sized networks, I can tell you to run
what your ops folks know best. We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.
-jim
Having run both on some good sized networks, I can tell you to run
what your ops folks know best. We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.
Agreed. I did an OSPFv3 vs. IS-IS bake-off in my lab several months ago as part of an IPv6 rollout, and one of the key deciding factors in going with OSPFv3 over IS-IS was that our ops folks are much more familiar with OSPFv2. While there are difference between OSPFv2 and OSPFv3 in how they work, the learning curve is a lot less steep than going from OSPFv2 to IS-IS.
jms
Awesome, I was thinking the same thing. Most experience is OSPF so it only
makes sense.
That is a good tip about OSPFv3 too. I will have to look more deeply into
OSPFv3.
Thanks,
-CJ
Granted, we're not a service provider, so we operate on a different scale
here, but one interesting trick that can be done with ISIS (at least on
Cisco) is this:
router a
Awesome, I was thinking the same thing. Most experience is OSPF so it only
makes sense.That is a good tip about OSPFv3 too. I will have to look more deeply into
OSPFv3.Thanks,
-CJ
Having run both on some good sized networks, I can tell you to run
what your ops folks know best. We can debate all day the technical
merits of one v another, but end of day, it always comes down to your
most jr ops eng having to make a change at 2 am, you need to design
for this case, if your using OSPF today and they know OSPF I'd say
stick with it to reduce the chance of things blowing up at 2am when
someone tries to 'fix' something else.-jim
I'm totally in concurrence with Stephan's point.
Couple of things to consider: a) deciding to migrate to either ISIS or
OSPFv3 from another protocol is still migrating to a new protocol
and b) even in the case of migrating to OSPFv3, there are fairly
significant changes in behavior from OSPFv2 to be aware of (most
notably
authentication, but that's fodder for another conversation).-Tony
This topic is a 'once a month' on NANOG, I'm sure we could check
the archives for some point-in-time research but I'm curious to learn
if anyone maintains statistics?
It would be interesting to see statistics on how many service providers run
either protocol. IS-IS has, for some years, been the de facto choice for SP's
and as a result the vendor and standardisation community 'used to' develop
SP features more often for IS-IS. IS-IS was, therefore, more 'mature' than OSPF
for SP's. I wonder if this is still the case?
For me, designing an IGP with IS-IS is much easier than it is with OSPF.
Mesh groups are far easier to plan (more straightforward) easier to change
than OSPF areas. As for junior noc staff touching much of anything to do
with an ISP's IGP at 2am, wake me up instead.
jy
The only reason in my opinion to run IS-IS rather than OSPF today is
due to the fact that IS-IS is decoupled from IP making it less
vulnerable to attacks.
how about simpler and more stable?
randy
I'll go with that... And one other thing... Traditionally it has been easier for developers to add new features to IS-IS because of the structure and flexibility of TLVs, whereas OSPF required the design of entirely new LSA types to support similar capabilities... I guess this has become less of an issue over the last few years however...
Nonetheless, if I was building a greenfield network today, I would personally go with IS-IS, but that is largely because of my many years working with the protocol...
Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
ISIS is also decoupled from IP making it more robust and
flexible/future-proof, as in adaptible to
new protocols -- IP connectivity is not required for ISIS nodes to
discover and associate with
L2 connected neighbors. At the fundamental level, there are plenty
of reasons to exclude
OSPF from running in a SP core; when a technically superior choice
is available and usable.
The IP decoupling is a good example.
As in, ISIS topology is independent from (non-tunneled) IP topology,
which is more flexible.
There is less complexity, and basic troubleshooting is facilitated
favorably to OSPFv2/v3, due
to the larger amount of baggage OSPF carries with it.
If you need to renumber your network, including IS-IS routers', you
will impact the contents
of IPv4 routes transmitted and forwarding table contents,
but your adjacencies do not rely on the IP protocol, and aren't
dependant on neighbor IP addressing.
Need to support IPv6 addresses? ISIS was trivially extended to do it.
Need to support routing to MAC addresses? Again... just a new type field.
OSPF requires... shall we say, more fundamental changes to attempt to
extend it.
More fundamental changes to a more complex protocol = more
opportunities for bugs.
I would encourage you to ask the opposite question: " Is there any
reason to run OSPF over IS-IS in the SP core?"
And the answer would be... probably not. There is not really a good
technical reason to run OSPF over IS-IS in the SP core.
You might have some aesthetic considerations such as wanting the SP
core to run the same protocol as something else,
despite its limitations.
Then you will have to ask yourself if the aesthetic considerations
outweigh the technical benefits.
Just to add to everything that Jimmy said, if you've got the time to do an in-depth side-by-side analysis of the two protocols, I strongly recommend the book "OSPF and IS-IS: Choosing an IGP for Large-Scale Networks" by Jeff Doyle. I can't speak highly enough of this book...
Stefan Fouant
JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
The only reason in my opinion to run IS-IS rather than OSPF today is
due to the fact that IS-IS is decoupled from IP making it less
vulnerable to attacks.how about simpler and more stable?
not rooted to a particular area.
supports more than one AFI at the same time
isn't dependent on ip addressing to form an adjacency
etc
If a network is big enough big / complex enough that you really need
to worry about performance of mesh groups or tweaking areas then its
big enough that having a noc eng page you out at 2am when there is an
issue doesn't really scale. I'm all for ISIS, if I was to build a
network from scratch I'd likely default to it. I'm just say, new
features or performance aside the knowledge of your team under you
will have much more impact on how your network runs then probably any
other factor. I've seen this time and time again when 'new tech' has
been introduced into networks, from vendors to protocols. Most every
time with engineers saying we have smart people they will learn it /
adjust. Almost every case of that turned into 6 mts of crap for both
ops and eng while the ops guys became clueful in the new tech, but as
a friend frequently says Your network, your choice.
-jim
You guys are making a lot of good points.
I will check into the Doyle book to formulate an opinion. So, I am
completely new to the SP environment and OSPF is what I have learned because
I have ever only had experience in the enterprise.
It seems that from this discussion, IS-IS is still a real, very viable
option. So, IS-IS being preferred...realistically, what is the learning
curve?
CJ
I would not say ISIS is the prefered protocol. Most service providers I have worked with use OSPF. Most networks outside of the US use it from what I have seen and the larger SPs in the US do too. There must be a reason for that.
Low, IMO. If you know EIGRP/OSPF, you'll have no trouble picking-up
IS-IS. Took me a few hours in a Cisco lab @ Uni to have it all
worked-out (interestingly that was about all the CCNP labs covered at
the time!)
Of course, knowing how the protocol works at a level suitable for
implementation in a critical network takes a bit longer, but you
shouldn't have any issue bootstrapping your test networks for that
purpose.
Tom
Actually, i strongly disagree with this statement. A good majority of the Tier-1 Service Providers that I have worked with in the past used IS-IS, I think in large part due to the points mentioned earlier. I know for a fact that in the late 90s, when we were transitioning from an ATM core to an MPLS core at UUnet, we selected IS-IS largely due to the fact that it supported MPLS Traffic Engineering extensions before comparable support was available in OSPF, and the main reason for this was due to the fact that IS-IS was TLV based.
Stefan Fouant
JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The learning curve isn't that big IMHO. However, it's all about comfort.
You should never design a network because "someone else does it this
way". While you can certainly take ideas into account about the WHY
their network looks that way, you need to look at your own needs and
desires to figure out if they line up.
If everyone in your organization knows OSPF. Why force the change? if
you can't come up with a good reason, then that's a great reason not to
do it, unless there is something missing from OSPF that you need.
The funny thing is that most people learn ISIS in conjunction with what
you already know (OSPF) and what the similarities/differences are in
terms of thinking.
Look at your current design. I'll assume that you have a reason for the
aspects of your network design that you currently have (as opposed to
someone else did it this way!). What are they? How will they translate
to ISIS? Will they translate? Do you care?
THAT kind of thing makes a good design for your company.
HTH,
Scott
You guys are making a lot of good points.
I will check into the Doyle book to formulate an opinion. So, I am
completely new to the SP environment and OSPF is what I have learned
because