IGP Comparison (Summary of Responses)

Tue Jan 5 18:34:21 UTC 1999

      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 at dbn.net