IGP Comparison (Summary of Responses)

Tue Jan 5 15:46:09 UTC 1999

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, although obviously some individuals are
satisfied enough with this protocol that is it still in place in large
networks.

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

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

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)

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..."
"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."
"Also, IS-IS made no attempt to align fields in their packet formats, making
life more difficult for protocol implementers."

"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.  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.  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, but it certainly diminishes the routing's
precision.  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)
Dr. Huitema goes on to state some advantages of OSPF over IS-IS:
* Support of a backup designated router
* Coexistence with RIP through "not-so-stubby-areas" [Okay, this ones a
little dated]
* 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.

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.

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.

OSPF: Is easier to implement and understand. It is more widely used, and
supported amongst many vendors.
IS-IS: Is more arcane. Harder to implement and understand it's operation
and behavior, and may not be supported on every router.

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

References:
(1)"Routing and the Internet" By: Christian Huitema (ISBN: 0131321927)
(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"
(http://www.faqs.org/rfcs/rfc1195.html)
RFC1371 "Choosing a "Common IGP" for the IP Internet (The IESG's
Recommendation to the IAB)" (http://www.faqs.org/rfcs/rfc1370.html)
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)
"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)

Dan Rabb
Network
digital broadcast network
dan at dbn.net