is-is and ospf a comparative anatomy dave katz, juniper networks

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

Upload: ashley-jerry

Post on 01-Apr-2015

242 views

Category:

Documents


4 download

TRANSCRIPT

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

IS-IS and OSPFA Comparative Anatomy

Dave Katz, Juniper Networks

Page 2: 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

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

June 12, 2000

Protocol History

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

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

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

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

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

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)

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

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

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

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)

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

June 12, 2000

Nuts and Bolts

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

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

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

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)

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

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)

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

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)

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

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)

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

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)

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

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)

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

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

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

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)

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

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)

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

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

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

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

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

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)

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

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

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

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)

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

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)

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

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

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

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)

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

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)

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

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

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

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

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

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

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

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

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

June 12, 2000

Scalability Issues

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

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

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

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

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

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

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

June 12, 2000

Pragmatic Considerations

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

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)

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

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)

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

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

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

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…)

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

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...

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

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

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

June 12, 2000

Conclusions

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

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

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

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

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

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

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

http://www.juniper.net