Hello Dan,
In the process of selecting an IGP to run on a large scale nationwide
IP Network, I received many responses to my NANOG request for information on
IS-IS versus OSPF protocols. Most of the resources mentioned in the
responses, however, were bias towards OSPF. There was not much
information on IS-IS to be found,
Yes, this is (IMHO) one of the main drawbacks of IS-IS. It has a
higher learning curve than OSPF, because there is less documentation.
although obviously some individuals are
satisfied enough with this protocol that is it still in place in large
networks.
Most of the large ISPs in the US run IS-IS as their IP IGP.
In europe a number of PTTs have chosen IS-IS as the IGP for their new
IP Internet backbones. That might be an indication if IS-IS is dead.
Thank you to everyone who responded to my request. Rather than responding to
each of you individually, I have summarized the information I received below
(although admittedly one-sided).
What's worse, some of the information below is simply not true.
Let me give you some more info.
And yes, I am biased towards IS-IS.
General:
"The two are really pretty much equivalent, other than that IS-IS is
intended for OSI networks while OSPF is for IP networks. Then there's
"Integrated IS-IS" that handles both."
IS-IS and "Integrated IS-IS" are just one and the same protocol.
In my opinion IS-IS defines fixed packet formats, plus a way to
extend the content of those packets with TLVs (Type Length Value).
Adjacency maintenance and a reliable flooding mechanism are also
part of IS-IS. The main goal of IS-IS is to determine the topology
of the network. Building routing tables is secondary to that.
"Integrated IS-IS" is just a bunch of extensions. Extra TLVs so IS-IS
can carry IP information. IS-IS can easily be extended to carry routing
information for IPv6 or any layer3 protocol. Have a look at NLSP, and
you will see ISIS carrying IPX routes and SAPs. Unfortunately Novell
defined NLSP in such a way that it is incompatible with ISIS.
IS-IS is defined in ISO document 10589. It defines the base structures
of the protocol (adjacencies, flooding, etc). Unfortunately it also
defines lots of CLNS specific TLVs. So it looks like ISIS is a routing
protocol for CLNS, and the IP thing is an add on. That is partly true,
but the ability to carry routing info for any layer3 protocol is a
well designed feature. I suspect IS-IS might be easier to understand
if the CLNS specific part was separated from the base protocol.
Politics:
"In fact, a number of members in the OSPF working group feared that IS-IS
would be preferred for "political" reasons, as part of a grand plan to
convert the Internet to OSI correctness, even if that meant a complete
disruption of the service."(1)
"There were also non-technical considerations. Many people felt that it was
better that the IETF have complete control over the OSPF protocol design
rather than depend on an ISO committee whose goals, namely to produce a
routing protocol for the OSI protocol stack, were somewhat different."(2)
This is all history, and should not be a reason for you to pick one
protocol over the other. The IETF has become what OSI was (and even
worse). Right now there are active OSPF *and* IS-IS workgroups. The IETF
can extend IS-IS as much as is needed.
Technical Issues:
The following are excerpt from John Moy's book discusses the reasons
that the IETF went ahead with the development of OSPF even though IS-IS was
already being developed:
"First, IS-IS ran directly over the link layer, which we thought was the
wrong choice for a TCP/IP routing protocol..."
IMHO it doesn't matter much. Strictly speaking routers should only need
to communicate with their direct neighbors. Unless you want virtual
links. (Yes, ISIS has them too, but for area partioning repair. They use
CLNS as tunnel encapsulation. I hate them even more than OSPF virtual
links).
FYI, at the Orlando IETF an internet draft by TonyP was discussed that
prososes an encapsulation scheme for IS-IS in IPv4 packets.
"IS-IS had an area routing scheme, but one that did not allow any shortcuts
between areas that we thought were necessary for an Internet routing
protocol."
Yes, OSPF allows virtual links. But there are different opinions regarding
the use of them. Some people say that if you use them, your network
design is already broken. Networks should be designed hierachical, or
you are gonna regret it later.
One of the obvious problems of VL is that instability in an area with
a VL can now influnece instability in area 0.
FYI, in IS-IS level-1 areas and the level-2 backbone can overlap. That
allows you to design a more robust leve-2 backbone, and alleviates the
need for virtual links.
"Also, IS-IS made no attempt to align fields in their packet formats, making
life more difficult for protocol implementers."
I totally disagree here.
IS-IS allows variable lenght fields (in the TLVs). An implementor just
knows that if he want to copy an integer out of a packet he has to
copy it byte-by-byte. That's all. Not all fields in packets are integers.
Whether an integer copy, a short copy, or a longlong copy takes more time
depends on the CPU type. Anyway, with today's fast CPUs, who cares about
the speed of byte copies in routing protocol packets ? (User traffic
forwarding is a different story).
The variable lenght TLVs make protocol extensions way more easier.
"It is possible to run IS-IS on an IP-only network, but, even if one does
not want to forward CLNP datagarms, one will have to install in the routers
the low-level code that demultiplexes CLNP and IS-IS packets.
IS-IS is not CLNP.
Yes, you need the low-level code to recognize "OSI traffic", and get
the ISIS packets (and maybe ignore the CLNS packets). If you plan to
run Gated on your Unix box, it migth matter. But if you buy a commercial
router product, do you care ?
The "area"
model of IS-IS is designed for CLNP where the rigidity and connectivity
requirements are somewhat compensated by the possibility to perform
automatic address assignment; when one uses IS-IS for IP, the rigidity
remains, but the advantages disappear.
This is true. In IS-IS all areas are stub areas.
Or to be exact, in the most popular IS-IS implementation IS-IS areas
are more like OSPF not-so-stubby-areas.
However, note that design guides typically advise you to use stub areas
in OSPF network designs. In most (hierarchical and redundant) networks
it hardly matters which ABR is chosen to get out of an area.
The only real problem here is if you are a ISP and do
shortest-exit-routing, or if you need to give MED to your customers
based on IGP distance to your BGP next-hops.
There is an IETF draft in the making that defines inter-area IP routes.
Once that is implemented, IS-IS will behave exactly the same as OSPF
regarding inter-area routes.
IS-IS suffers from at least two
other problems; a tiny metric and a limit to what a router can advertise.
Having only 6 bits to express a link's metric is not really a good idea. It
may make some messages shorter,
Using 6 bits has nothing to do with making LSPs smaller.
It is done to assure the total path metric can be assumed to be under 1023.
That will allow implementors to use a trick during sorting of the tentative
list during SPF. This will bring the theoretical complexity of SPF from
O(n log n) to O(n). However, in real life it probably hardly matters.
FYI the upcoming draft that will define interarea IP routes will also
defines some more new TLVs, and will use more bits for the metric.
but it certainly dimnishes the routing's precision.
Most ISPs use hand-picked metrics. They don't want automatic metrics.
In that case the precision is less important. With some puzzling you
can get what you want. But yes, sometimes this puzzling gets a bit nasty.
Then, using the 8-bit link state record number to identify the
link state record's will limit to 256 the number of records that a given
router can advertise. As the size of each record is limited to the maximum
packet size supported by the network, this can prove to be a severe
constraint."(1)
FYI, the default max lsp-size is 1492 bytes. 256 fragments of 1492
bytes gives enough room to store 30K IP routes. More than you want.
If you are gonna carry many IP routes in your IGP, it is way better
to carry them in BGP.
Sometimes it is nice to flood only information that has changed.
Like in OSPF when only a single external route changes.
But sometimes it is a drawback.
Real life has shown that LSP/LSA flooding is way more of a scaling
issue than running SPFs. In heavily meshed networks a router will
see many copies of the same LSP/LSA. Only the first time a router
sees the new LSP/LSA is will store it in the LSDB. All the other
copies of that same LSP/LSA will be ignored. But they need to be send,
acknowledged, etc. That is a lot of work for many small LSAs (in OSPF).
It is more effective to just flood a few larger LSPs (in IS-IS).
Dr. Huitema goes on to state some advantages of OSPF over IS-IS:
* Support of a backup designated router
Yeah, right.
Dr Huitema clearly needs a little education.
Flooding in OSPF over a LAN is painful. When the DR goes down, we need
a new DR. All routers on the LAN need to sync with the new DR. That
takes a lot of time. So OSPF needed an ugly hack like the BDR. It keeps
DR changes acceptable, but adds a lot of complexity. IS-IS uses CSNPS
in a scheme that is a lot more simpler and elegant.
* Coexistence with RIP through "not-so-stubby-areas" [Okay, this ones a
little dated]
Same can be done in IS-IS. (If you ignore the part in rfc1195 that
says you can't advertise externals in L1 LSPs).
* OSPF is "change controlled" by the IETF, evolution of OSI Protocols was
much slower and that it responded to many other forces besides user needs.
IS-IS has it's own IETF WG. And many new drafts.
Ron Johnson wrote:
OSPF: Uses a multicast address and standard IP transport to carry it's
packets.
IS-IS: Uses it own transport method to carry it's packets.
IS-IS is encapsulated directly in the datalink layer.
Only an issue when you us ATM. IS-IS and IP over ATM require snap or
nlpid encaps, which adds enough bytes so a TCP ack won't fit into
one ATM cell. You'll waste some extra percentage of your BW. OSPF
allows null encaps, and a TCP ack will just fit into one cell.
IS-IS in IP encapsultation is on it's way.
OSPF: Scales well when the Backbone/area/stub model is correctly
implemented, otherwise with many routers in a single area, it can have a
definite performance impact on routing convergence times.
IS-IS: Is less sensitive to growth problems then OSPF.
Most ISPs run their backbone as one IS-IS area. (Because there are
no inter-area routes from level-2 into level-1). This is not a public
statement, so don't hold me responsible. But I believe that in a cisco
network, with MIPS based boxes and running dCEF, and enough BW (T1s or
so) you can probably easily put a 1000 routers or more in one area.
In that case you don't need to mess with areas. Is a 1000 routers
in one network enough for you ?
Again, don't build a 1000 router network and when it breaks come
complaining. Please contact your cisco SE (or me) if you plan to
do this. 
OSPF: Is easier to implement and understand. It is more widely used, and
supported amongst many vendors.
That is true. More documentation and more experience.
Note, many router vendors have implemented IS-IS recently, or are
working on it.
IS-IS: Is more arcane. Harder to implement and understand it's operation
and behavior, and may not be supported on every router.
Mmmm, actually I think IS-IS is easier to troubleshoot and predict
once you understand the basics.
So, the bottom line, for me is; Use OSPF V2, if you are building a network
where you can create a "backbone" area and then other logical areas
attached to the backbone. Then aggregate and summarize your route
announcements in your areas and announce the summarized routes into the
backbone area.
Summarization. That is good network design.
But is also indicates you care less about "routing precision".
So IMO there are no substantial benefits in OSPF over IS-IS.
You will end up with less routes in your IGP. Which in turn means lower
OSPF recalculation times, better performance and a more stable IGP.
Of course.
Same design rules apply for both OSPF and ISIS.
References:
(1)"Routing and the Internet" By: Christian Huitema (ISBN: 0131321927)
If the rest of the book is as accurate as the quotes in your email,
better throw away this book. 
(2)"OSPF Anatomy of an Internet Routing Protocol" By: John Moy (ISBN:
0201634724)
"Routing TCP/IP Volume I" By: Jeff Doyle, CCIE (ISBN:1578700418)
RFC2178 "OSPF Version 2" (http://www.faqs.org/rfcs/rfc2178.html)
RFC1195 "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments"
(RFC 1195 - Use of OSI IS-IS for routing in TCP/IP and dual envir (RFC1195))
RFC1371 "Choosing a "Common IGP" for the IP Internet (The IESG's
Recommendation to the IAB)" (RFC 1370 - Applicability Statement for OSPF (RFC1370))
Previous NANOG Discussions on this topic:
http://www.cctec.com/maillists/nanog/historical/9810/threads.html#00484
Other References I have yet to review:
"Interconnections: Bridges and Routers" By: Radia Perlman (ISBN:
0201563320)
Biased towards IS-IS. Maybe you should have read it.
"The Great IGP Debate--Part One:IS-IS and Integrated Routing." By: R.
Perlman and R. Callon (ConneXions 5, no. 10, October 1991)
"The Great IGP Debate--Part Two:The Open Shortest Path First (OSPF) Routing
Protocol." (ConneXions 5, no. 10, October 1991)
I haven't read these. Old stuff, I guess they are less relevant now.
Bottomline, OSPF and ISIS are very similar. The differences might
be meaningful in some network, and not in others. Personally I prefer ISIS.
It is simpler and more elegant. Thus (IMHO) easier to implement and deploy.
Which should result in more scalable and robust implementations.
I just wanted to discuss some of the opinions given by others.
Hope it helps.
Regards,
Henk