IS-IS and OSPF A Comparative Anatomy Dave Katz, Juniper Networks

June 12, 2000 Overview  Protocol History  Nuts and Bolts  Scalability Issues  Pragmatic Considerations  Conclusions

June 12, 2000 Protocol History

June 12, 2000 Protocol History  (Disclaimer--biased, foggy memory)  1987  IS-IS (from DEC) selected by ANSI as OSI intradomain protocol (CLNP only)  1988  NSFnet deployed, IGP based on early IS-IS draft  OSPF work begins, loosely based on IS-IS mechanisms (LS protocols are hard!)  IP extensions to IS-IS defined

June 12, 2000 Protocol History  1989  OSPF v.1 RFC published  Proteon ships OSPF  IS-IS becomes ISO proposed standard  Public bickering ensues--OSPF and IS-IS are blessed as equals by IETF, with OSPF somewhat more equal  Private cooperation improves both protocols  1990  Dual-mode IS-IS RFC published

June 12, 2000 Protocol History  1991  OSPF v.2 RFC published  Cisco ships OSPF  Cisco ships OSI-only IS-IS  1992  Cisco ships dual IS-IS (part of DEC Brouter)  Lots of OSPF deployed, but very little IS-IS  1993  Novell publishes NLSP (IPX IS-IS knockoff)

June 12, 2000 Protocol History  1994  Cisco ships NLSP (rewriting IS-IS as side effect)  Large ISPs need an IGP; IS-IS is recommended due to recent rewrite and OSPF field experience (and to lesser extent, NSF CLNP mandate)  1995  ISPs begin deployment of IS-IS, Cisco implementation firms up, protocol starts to become popular in niche

June 12, 2000 Protocol History   IS-IS niche popularity continues to grow (some ISPs switch to it from OSPF)  IS-IS becomes barrier to entry for router vendors targeting large ISPs  Juniper and other vendors ship IS-IS capable routers   Extensions continue for both protocols (e.g, Traffic Engineering)

June 12, 2000 Nuts and Bolts

June 12, 2000 Nuts and Bolts  10,000 foot view  Protocols are recognizably similar in function and mechanism (unsurprising, given common heritage)  Link state algorithms (network map is distributed, each router calculates routes independently based on the map)  Two level hierarchies  Designated Router on LANs  Widely deployed (for some value of “wide”)  Multiple interoperable implementations

June 12, 2000 Nuts and Bolts  10,000 foot view  OSPF is for the most part more “optimized” (and therefore significantly more complex)  IS-IS was not designed from the start as an IP routing protocol (and is therefore a bit clunky in places)

June 12, 2000 Nuts and Bolts  Encapsulation  OSPF runs on top of IP  Traditional IP routing protocol approach  Allows virtual links (if you like them)  Relies on IP fragmentation for large LSAs  Subject to spoofing and DoS attacks (use of authentication is strongly advised)  Allows use of ATM VCmux encapsulation (so TCP acks fit in one ATM cell)

June 12, 2000 Nuts and Bolts  Encapsulation  IS-IS runs directly over L2 (next to IP)  Sort of makes sense, architecturally  Partition repair requires tunneling (rarely implemented)  More difficult to spoof or attack  More difficult to implement in some environments  Requires ATM SNAP encapsulation, forcing two-cell TCP acks (but Henk Smit’s NLPID hack fixes this)

June 12, 2000 Nuts and Bolts  Media support  Both protocols support LANs and point-to-point links in similar ways  IS-IS has no direct NBMA support--expects O/S to present NBMA network as either pseudo-LAN (bad idea) or set of point-to-point links  OSPF NBMA mode is configuration-heavy and risky (all routers must be able to reach DR; bad news if VC fails)  OSPF P2MP mode models NBMA as point-to- point links (if O/S won’t help)

June 12, 2000 Nuts and Bolts  Packet Encoding  OSPF is “efficiently” encoded  Positional fields  Holy 32-bit alignment provides tidy packet pictures, but not much else  Only LSAs are extensible (not Hellos, etc.)  Unrecognized LSA types not flooded (though opaque LSAs can suffice, if implemented universally, and IS-IS-like encoding can provide good granularity)

June 12, 2000 Nuts and Bolts  Packet Encoding  IS-IS is mostly Type-Length-Value encoded  No particular alignment  Extensible from the start (unknown types ignored but still flooded)  All packet types are extensible  Nested TLVs provide structure for more granular extension (though base spec does not use them; OSPF is starting to do so)

June 12, 2000 Nuts and Bolts  Area Architecture  Both protocols support two-level hierarchy of areas (to reduce SPF graph complexity, and potentially to allow route aggregation)  OSPF area boundaries fall within a router  Interfaces bound to areas  Router may be in many areas  Router must calculate SPF per area

June 12, 2000 Nuts and Bolts  Area Architecture  IS-IS area boundaries fall on links  Router is in only one area, plus perhaps the L2 backbone (area)  Biased toward large areas, area migration  Requires router per area (unless multiple virtual routers are implemented)  Historically proven somewhat difficult for users to grasp  Little or no multilevel deployment (large flat areas work so far)

June 12, 2000 Nuts and Bolts  Database Granularity  OSPF database node is an LSAdvertisement  LSAs are mostly numerous and small (one external per LSA, one summary per LSA)  Network and Router LSAs can become large  LSAs grouped into LSUpdates during flooding  LSUpdates are built individually at each hop  Small changes can yield small packets (but Router, Network LSAs can be large)

June 12, 2000 Nuts and Bolts  Database Granularity  IS-IS database node is an LSPacket  LSPs are clumps of topology information organized by the originating router  Always flooded intact, unchanged across all flooding hops (so LSP MTU is an architectural constant--it must fit across all links)  Small topology changes always yield entire LSPs (though packet size turns out to be much less of an issue than packet count)  Implementations can attempt clever packing

June 12, 2000 Nuts and Bolts  Neighbor Establishment  Both protocols use periodic multicast Hello packets, “I heard you” mechanism to establish 2-way communication  Both protocols have settable hello/holding timers to allow tradeoff between stability, overhead, and responsiveness  OSPF requires hello and holding timers to match on all routers on the same subnet (side effect of DR election algorithm) making it difficult to change timers without disruption

June 12, 2000 Nuts and Bolts  Neighbor Establishment  IS-IS requires padding of Hello packets to full MTU size under some conditions (to detect media with MTUs smaller than 1497 bytes)-- this is effectively useless and causes needless support calls (deprecated in practice)  OSPF requires routers to have matching MTUs in order to become adjacent (or LSA flooding may fail, since LSUpdates are built at each hop and may be MTU-sized)

June 12, 2000 Nuts and Bolts  Neighbor Adjacency Establishment  The goal--synchronize databases  The method--tell your neighbor everything you’ve got  You (or your neighbor) will figure out what you’re missing and make sure that you get it  Each protocol’s approach is driven by database granularity

June 12, 2000 Nuts and Bolts  Neighbor Adjacency Establishment  OSPF uses complex, multistate process to synchronize databases between neighbors  Intended to minimize transient routing problems by ensuring that a newborn router has nearly complete routing information before it begins carrying traffic  Accounts for a significant portion of OSPF’s implementation complexity  Partially a side effect of granular database (requires many DBD packets)

June 12, 2000 Nuts and Bolts  Neighbor Adjacency Establishment  IS-IS essentially uses its regular flooding techniques to synchronize neighbors (that’s what flooding naturally does)  Coarse database granularity makes this easy (just a few CSNPs)  Transient routing issues can be reduced (albeit nondeterministically) by judicious use of the “overload” bit (one of a number of opportunistic hacks)

June 12, 2000 Nuts and Bolts  Designated Routers and Adjacency  Both protocols elect a designated router on multiaccess networks to remove O(N^2) link problem (by creating a pseudonode) and to reduce flooding traffic (DR ensures flooding reliability)  OSPF elects both a DR and a Backup DR, each of which becomes adjacent with all other routers  BDR takes over if DR fails  DRship is sticky, not deterministic  Complex algorithm

June 12, 2000 Nuts and Bolts  Designated Routers and Adjacency  In IS-IS all routers are adjacent (but adjacency is far less stateful)  If DR dies, new DR must be elected, with short connectivity loss (synchronization is fast)  DRship is deterministic (highest priority, highest MAC address always wins)  DRship can be made sticky by cool NLSP priority hack (DR increases its DR priority)

June 12, 2000 Nuts and Bolts  LAN Flooding  OSPF uses multicast send, unicast ack from DR  Reduces flood traffic by 50% (uninteresting)  Requires per-neighbor state (for retransmissions)  Interesting (but complex) acknowledgement suppression  Flood traffic grows as O(N)

June 12, 2000 Nuts and Bolts  LAN Flooding  IS-IS uses multicast LSP from all routers, CSNP from DR  Periodic CSNPs ensure databases are synced (tractable because of coarse database granularity)  Flood traffic constant regardless of number of neighbors on LAN  But big LANs are uninteresting

June 12, 2000 Nuts and Bolts  Routes and Metrics  IS-IS base spec used 6-bit metrics on links  Allowed an uninteresting SPF optimization (CPUs are fast these days)  Proved difficult to assign meaningful metrics in large networks  Wide metric extension addresses this  Dual IS-IS spec advertises only default into L1 areas  Interarea traffic routed suboptimally  Route leaking extension addresses this

June 12, 2000 Nuts and Bolts  Authentication and Security  Both support cryptographic authentication  OSPF really needs this (packet bombs)  Successful IGP attacks will be catastrophic (or worse, subtle)  Use packet filtering, particularly with OSPF

June 12, 2000 Nuts and Bolts  MPLS Traffic Engineering extensions  Protocols carry around TE link information (available bandwidth, link color, etc.) on behalf of MPLS but don’t use the data themselves  TE functionality is identical for the two protocols (by design)  TE functions are IGP-independent, so mechanisms ought to be identical

June 12, 2000 Scalability Issues

June 12, 2000 Scalability Issues  Database Size  OSPF topologies limited by Network and Router LSA size (max 64KB) to O(5000) links  External and Interarea routes are essentially unbounded  IS-IS topologies limited by LSP count (256 fragments * 1470 bytes) for all route types  Various hacks (fake pseudonodes, etc.) could make this bigger  Ultimately a non-issue for even slightly sane topologies

June 12, 2000 Scalability Issues  Database Churn  Both protocols have time-limited database entries and therefore require refreshing  IS-IS lifetime field is 16 bits, giving 18.7-hour lifetimes (with refresh times close to this)  OSPF age (counts up) has an architectural lifetime limit of 1 hour (80,000 LSAs yield a refresh every 23 milliseconds)  “Do-not-age” LSAs are not backward compatible  Don’t inject zillions of routes into your IGP

June 12, 2000 Scalability Issues  Flooding load--the only serious issue  Full-mesh topologies are worst-case for both  N^2 copies of each update (each of which is O(N) in size)  Link failure: O(N^3) information  Router failure: O(N^4) information  IS-IS “mesh group” hack provides backward- compatible way of pruning flooding topology  OSPF has no solution without protocol change

June 12, 2000 Pragmatic Considerations

June 12, 2000 Pragmatic Considerations  OSPF spec is an excellent implementation guide  If followed to the letter, a working, if naïve, implementation will likely result  Spec is complex but has almost no “why” information, so other (potentially more scalable) implementation approaches are at the implementor’s own risk  Barrier to entry in high-end router market (you need to know the protocol intuitively)

June 12, 2000 Pragmatic Considerations  IS-IS spec uses arcane ISOspeak and has very few implementation hints  Spec is inherently simple (once you get the lingo), with fewer implementation issues  Boilerplate at front and back of spec means that you can lose pages without affecting content  Barrier to entry in high-end router market (you need to know the protocol intuitively)

June 12, 2000 Pragmatic Considerations  Extensibility  Despite anti-OSI FUD, IS-IS has proven much easier politically to extend (primarily due to small constituency and IETF disinterest)  Self-interest of router vendors and large ISPs brings extensions more quickly in IS-IS and promotes implementation stability, scalability, and interoperability

June 12, 2000 Pragmatic Considerations  Extensibility  OSPF’s encoding scheme difficult to extend  Difficult compatibility issues  Explicitly and proudly optimized for IPv4  IPv6 requires a completely new protocol  IS-IS encoding inefficient and simple-minded  But proven to be easy to extend, at least in some ways  “IPv6-Ready” (also IPX-Ready…)

June 12, 2000 Pragmatic Considerations  Optimality  OSPF was optimized for things that don’t matter any more (link bandwidth, CPU alignment)  IS-IS was optimized for things that don’t matter any more (large LANs, SPF cost)  Optimizations turn out to add complexity but not much value  A lot has changed in 10 years...

June 12, 2000 Pragmatic Considerations  OSPF is much more widely understood  Broadly deployed in enterprise market  Many books of varying quality available  Preserves our investment in terminology  IS-IS is well understood within a niche  Broadly deployed within the large ISP market  Folks who build very large, very visible networks are comfortable with it

June 12, 2000 Conclusions

June 12, 2000 Conclusions  For all but extreme cases (large full-mesh networks), protocols are pretty much equivalent in scalability and functionality  Stability and scalability are largely artifacts of implementation, not protocol design  Familiarity and comfort in both engineering and operations is probably the biggest factor in choosing

June 12, 2000 Conclusions  Does the world really need two protocols?  Nearly complete overlap in functionality means (ironically) that few people are motivated to switch  Entrenched constituencies (large ISPs; everyone else) ensure that installed bases will continue to exist  As long as there are two, people will never agree on only one  Not even the oft-predicted demise of IPv4 will suffice

June 12, 2000 Conclusions  Both protocols are over 10 years old, using graph theory that’s at least 40 years old  Both protocols are (even still) works in progress  Cherish Diversity (and job security)  They’re both good protocols  Use the one that makes the most sense to you