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" (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)

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

Dan Rabb Network digital broadcast network dan@dbn.net