OSPF vs ISIS - Which do you prefer & why?

Mailman List Mirror (Read Only)
1

Greetings Team,

​While I haven't worked with IS-IS before but the only disadvantage I've
encountered with OSPF is that it is resource intensive on the router it is
running on which is why only one instance runs on any PE & P device on an
ISP network. OSPF is pretty good in handling the core network routing while
BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP
can run on top of OSPF. I came across this *article*
<https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/>
when
scrolling the web a while back and I still want to find out if am the only
one who thinks its a matter of choice between the two. Although there isn't
distinct 1:1 argument, it's good we discuss it here and figure out why one
prefer one over the other *(consider a huge flat network)**.* What say you
ladies and gentlemen?

Warm regards,

Michael Bullut.

2

vi users prefer ospf
emacs users prefer is-is

randy

3

So that leaves EIGRP for the nano users?

David Barak

4

vi users prefer ospf
emacs users prefer is-is

So that leaves EIGRP for the nano users?

teco

5

I will definitely be looking up the notes from AOL that John referenced.
But working for a vendor and getting insight from multiple ISPs, here are a
few of the things that I hear most frequently:

1) Network Topology support - The differences between a single OSPF
backbone area and a contiguous set of Level-2 adjacencies will occasionally
be a deciding factor.
2) Feature Support on a per vendor basis - Some vendors will roll new
features out in one or the other protocols prior to the other. Segment
Routing and some of its enhancements come to mind as being in ISIS first.
3) Layer 2 adjacencies - I think someone already mentioned that you form
adjacencies at layer 2 which also means that with a single adj you can
support multiple protocols (v4/v6). OSPF would require two different
instances to support both. Maybe good, maybe not. Depends on your desired
level of isolation between the two.
4) CPU performance is academic at this point - The SPF calculations in most
networks would require next to no difference between the two protocols even
if running both IPv4 and v6.

End of the day, use the right tool/vendor/technology for the right job.

Hope this helps,
RT

6

Vendor support for IS-IS is quite limited - many options for OSPF.

7

I've given a talk about this a couple of times since 2008. But our
reasons are to choosing IS-IS are:

  * No requirement to home everything back to Area 0 (Virtual Links are
    evil).

  * Integrated IPv4/IPv6 protocol support in a single IGP implementation.

  * Single level (L2) deployment at scale.

  * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3
    employs a TLV structure, however.

  * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may
    not be available on all vendor implementations.

If you're interested in reviewing the talk I gave on this, a lot more
details is in there at:

http://www.apricot.net/apricot2009/images/lecture_files/isis_deployment.pdf

Ultimately, router CPU's are way faster now, and I could see a case for
running a single-area OSPFv2. So I'd likely not be religious about
forcing you down the IS-IS path.

Mark.

8

And yes, IS-IS not running over IP is also a great thing.

Mark.

9

1) Network Topology support - The differences between a single OSPF
backbone area and a contiguous set of Level-2 adjacencies will occasionally
be a deciding factor.

L2 IS-IS can be as chatty as single-area OSPF. That said, IS-IS has
native tools to reduce that chatter (like PRC, and iSPF), but to be
honest, I'm not sure it makes much of a difference given today's faster
router CPU's.

2) Feature Support on a per vendor basis - Some vendors will roll new
features out in one or the other protocols prior to the other. Segment
Routing and some of its enhancements come to mind as being in ISIS first.

I've noticed that the delay between when IS-IS and/or OSPF pick up a
feature the other already has is reasonable. By the time an OSPF has
completed evaluating whether they need LFA, it would have been
implemented in the IGP.

I suppose back then, there was a much bigger between when features made
it between both protocols, but things seem to be on par nowadays.

3) Layer 2 adjacencies - I think someone already mentioned that you form
adjacencies at layer 2 which also means that with a single adj you can
support multiple protocols (v4/v6). OSPF would require two different
instances to support both. Maybe good, maybe not. Depends on your desired
level of isolation between the two.

OSPFv3 can support the advertisement of IPv4 prefixes. But you'd still
need an IPv6 link layer.

4) CPU performance is academic at this point - The SPF calculations in most
networks would require next to no difference between the two protocols even
if running both IPv4 and v6.

Agree.

End of the day, use the right tool/vendor/technology for the right job.

Agree.

Mark.

10

Depends on the vendor.

Cisco have as many knobs for IS-IS as they do for OSPF.

Juniper, not so much.

Don't know about other vendors.

At any rate, many of these knobs are not part of the original protocol
spec., although they can be very useful when scaling.

Mark.

11

This generally supports my own view that it depends on the topology
and the real or potential scale/scope. In my experience, IS-IS is just
all around better in a flat, highly interconnected environment such as
an ISP or other broadly scaled network. If you have a very (almost
exclusively) heirarchical structure and pretty good control over IP
addressing and can use summarization effectively, then OSPF can make
your core networking much simpler. On a small network that doesn't
look to grow at leaps and bounds, I'd favor OSPF. On a large, complex
network or a network that has the potential to grow without any sort
of predefined structure (ie, more demand based), then IS-IS is
probably your win. Note that this doesn't factor in multiple IS-IS
levels, something I don't have a great deal of experience with.
Mostly, networks I've been associated with just run one great big,
gigantic level 0, though they did also experiment with other
configurations.

-Wayne

12

This generally supports my own view that it depends on the topology
and the real or potential scale/scope. In my experience, IS-IS is just
all around better in a flat, highly interconnected environment such as
an ISP or other broadly scaled network. If you have a very (almost
exclusively) heirarchical structure and pretty good control over IP
addressing and can use summarization effectively, then OSPF can make
your core networking much simpler. On a small network that doesn't
look to grow at leaps and bounds, I'd favor OSPF. On a large, complex
network or a network that has the potential to grow without any sort
of predefined structure (ie, more demand based), then IS-IS is
probably your win.

I wouldn't base the choice necessarily on the size of the network,
although from experience, I'd always choose IS-IS for a large,
geographically-dispersed network.

What I mean to say is that I'd be happy running IS-IS on a tiny network,
as much as I'd run route reflectors in a 3-router network. There isn't
that much more effort to get it going compared to considering whether a
Mini or a dump truck should be used to take the kids to school every
morning.

Note that this doesn't factor in multiple IS-IS
levels, something I don't have a great deal of experience with.
Mostly, networks I've been associated with just run one great big,
gigantic level 0, though they did also experiment with other
configurations.

I've run multi-level IS-IS before. To be honest, I'd not recommend it.

There are enough features and knobs in IS-IS to quiet the chatter
associated with a single-level IS-IS deployment.

Running multi-level IS-IS means you need to plan your L1/L2
intersections, figure out what to do with the ATT Bit and look at Route
Leaking if you run MPLS (LDP hates route summarization).

Needless to say, the Area ID of the NET is more significant in L1/L2
IS-IS than in L2-only IS-IS, as this is what is used to control LSP
exchange between levels. This can get very complicated very fast in very
large networks. Yep, that's 3 "very's".

It's 2016, and any decent router has something-x86 going for it (or at
the very least, a reasonably quick non-x86 going for it). I'd stick to
single-level IS-IS. Which means L2-only, not L1-only - I know a network :-).

My only real issue with IS-IS is the ST and MT (Single Topology and
Multi-Topology) nuisance re: IPv6. Many vendors implement ST on turn-up,
meaning you need to manually configure the MT knob. This can be painful
when you haven't been clued up on MT, run an IPv4-only network and need
to enable IPv6. I've gone into a bit of detail on this in my talk that I
included in a previous post.

Mark.

13

Running multi-level IS-IS means you need to plan your L1/L2
intersections

as painful as ospf

in a research rack with more than one router, i run is-is.

randy

14

as painful as ospf

If I did run OSPF, I'd probably do it with a single area, likely OSPFv3
with IPv4 address family support. Kinky, but it is 2016...

in a research rack with more than one router, i run is-is.

Good man :-)...

Mark.

15

Greetings Team,

While I haven't worked with IS-IS before but the only disadvantage I've
encountered with OSPF is that it is resource intensive on the router it is
running on which is why only one instance runs on any PE & P device on an
ISP network. OSPF is pretty good in handling the core network routing while
BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP
can run on top of OSPF. I came across this *article*
<https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/>
when
scrolling the web a while back and I still want to find out if am the only
one who thinks its a matter of choice between the two. Although there isn't
distinct 1:1 argument, it's good we discuss it here and figure out why one
prefer one over the other *(consider a huge flat network)**.* What say you
ladies and gentlemen?

I've given a talk about this a couple of times since 2008. But our
reasons are to choosing IS-IS are:

I don't think there is much of a debate to be had any more, the gap
between them is so small now (OSPFv3 and ISIS that is, no one would
deploy OSPFv2 now in greenfield right?):

  * No requirement to home everything back to Area 0 (Virtual Links are
    evil).

This is a good point I think.

  * Integrated IPv4/IPv6 protocol support in a single IGP implementation.

This is in OSPv3.

  * Single level (L2) deployment at scale.

Single area 0 deployment at scale? Bit of a moot point unless you
compare a specific device model and specific code version in two
identical deployments, its not much to do with the protocol but the
vendor implementation and the brute force.

  * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3
    employs a TLV structure, however.

OSPv3 has this.

  * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may
    not be available on all vendor implementations.

OSPF has these too.

Ultimately, router CPU's are way faster now, and I could see a case for
running a single-area OSPFv2. So I'd likely not be religious about
forcing you down the IS-IS path.

Yeah this ^ I don't think there is a stronge case for either protocol.

Somenoe mentioned the AOL NANOG talk about migrating from OSPF to
ISIS. There was a NANOG talk recently-ish about someone migrating from
OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better
for them (in the DC).

BGP these days supports PIC and BFD etc, how much longer to IGPs have? :slight_smile:

James.

16

Dne 10.11.16 v 11:17 James Bensley wrote:

  * Integrated IPv4/IPv6 protocol support in a single IGP implementation.

This is in OSPv3.

In theory, yes. In the real world operators need MPLS label
distribution, which is still not supported in many implementations.

Regards,
Zbynek

17

I don't think there is much of a debate to be had any more, the gap
between them is so small now (OSPFv3 and ISIS that is, no one would
deploy OSPFv2 now in greenfield right?):

Most networks that I know are greenfielding an IGP will deploy both
OSPFv2 and OSPFv3. Worst case, just OSPFv2.

This is in OSPv3.

Right, but if a network does not yet want to run IPv6 (2016, anyone),
then this becomes an issue as IPv6 NLRI is carried over the IPv6 transport.

This could also come down to implementation. I looked at this for the
first time back in Junos 9.0 (when it was still an IETF draft), and no
other vendor had it yet. It has since matured and I know both Juniper
and Cisco have decent code.

I can't speak for other vendors, particularly if you multi-vendor.

Single area 0 deployment at scale? Bit of a moot point unless you
compare a specific device model and specific code version in two
identical deployments, its not much to do with the protocol but the
vendor implementation and the brute force.

Like I said to Randy, if I did deploy OSPF ever (quite unlikely), there
is enough CPU in today's router to, I think, run a single Area 0 for the
whole thing.

OSPv3 has this.

Yep, as I did mention.

OSPF has these too.

More of them in OSPFv3 than OSPFv2. But then again, vendor-specific
knobs can be had here for cheap.

Yeah this ^ I don't think there is a stronge case for either protocol.

Somenoe mentioned the AOL NANOG talk about migrating from OSPF to
ISIS. There was a NANOG talk recently-ish about someone migrating from
OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better
for them (in the DC).

BGP these days supports PIC and BFD etc, how much longer to IGPs have? :slight_smile:

Sounds like you're talking about BGP-LS.

If you are, then BGP-LS still requires an IGP. It's just that the IGP
has a much more micro view of the network, while BGP-LS is tasked with
the macro side of things.

Mark.

18

But dual-stack protocol support in the IGP has nothing to do with MPLS.

Now, if you're talking about LDPv6 or SR, then...

Mark.

19

Cisco is the only "real" IS-IS vendor.

Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the
whitebox hardware or real SDN capable solutions, you're going to be on OSPF.

20

Cisco is the only "real" IS-IS vendor.

Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the
whitebox hardware or real SDN capable solutions, you're going to be on OSPF.

Maybe you need to tell us what the other companies aren't getting?
We're using IS-IS on (mostly) Juniper and Huawei, but also Alcatel/
Lucent/Nokia and Cisco. It just works.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no