IS-IS and OSPF A Comparative Anatomy

							       IS-IS and OSPF
A Comparative Anatomy

Dave Katz, Juniper Networks
                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

  1996-1998
        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
  1999-2000
        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



June 12, 2000
http://www.juniper.net