Upload
fausta
View
19
Download
0
Tags:
Embed Size (px)
DESCRIPTION
IS-IS and OSPF A Comparative Anatomy. Dave Katz, Juniper Networks. Overview. Protocol History Nuts and Bolts Scalability Issues Pragmatic Considerations Conclusions. Protocol History. Protocol History. (Disclaimer--biased, foggy memory) 1987 - PowerPoint PPT Presentation
Citation preview
IS-IS and OSPFA 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
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 approachAllows virtual links (if you like them)Relies on IP fragmentation for large LSAsSubject 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, architecturallyPartition repair requires tunneling
(rarely implemented)More difficult to spoof or attackMore difficult to implement in some
environmentsRequires 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 fieldsHoly 32-bit alignment provides tidy
packet pictures, but not much elseOnly 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
encodedNo particular alignmentExtensible from the start (unknown
types ignored but still flooded)All packet types are extensibleNested 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 routerInterfaces bound to areasRouter may be in many areasRouter 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 migrationRequires router per area (unless multiple
virtual routers are implemented)Historically proven somewhat difficult for
users to graspLittle 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 largeLSAs grouped into LSUpdates during floodingLSUpdates 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 neighborsIntended 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 routersBDR takes over if DR failsDRship is sticky, not deterministicComplex 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 DRReduces flood traffic by 50%
(uninteresting)Requires per-neighbor state (for
retransmissions)Interesting (but complex)
acknowledgement suppressionFlood traffic grows as O(N)
June 12, 2000
Nuts and Bolts
LAN Flooding IS-IS uses multicast LSP from all routers,
CSNP from DRPeriodic 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 areasInterarea traffic routed suboptimallyRoute 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) linksExternal and Interarea routes are
essentially unbounded IS-IS topologies limited by LSP count (256
fragments * 1470 bytes) for all route typesVarious 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 issuesExplicitly and proudly optimized for IPv4IPv6 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
http://www.juniper.net