Re: Fwd: OSPF & ISIS Contrasts

From: Peter van Oene (pvo@usermail.com)
Date: Mon Oct 21 2002 - 14:01:50 GMT-3


That would be the ospf group of course, not the ospp :)

At 12:31 PM 10/21/2002 -0400, you wrote:
>In keeping with Howard's OSPF vs ISIS variances thread, I thought I would
>post this gem from Radia Perlman which she posted recently to the OSPP WG
>in the IETF. Interesting historical points
>
>>X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc
>>Date: Sat, 31 Aug 2002 22:04:15 -0400
>>Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
>>Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
>>From: Radia Perlman - Boston Center for
>>Networking <Radia.Perlman@SUN.COM>
>>Subject: Re: what is the fundamental difference between OSPF and IS-IS?
>>To: OSPF@DISCUSS.MICROSOFT.COM
>>X-Spam-Status: No, hits=1.0 required=9.2
>> tests=SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD
>> version=2.31
>>X-Spam-Level: *
>>
>> From: "Liu B." <binl@EEE-FS7.BHAM.AC.UK>
>> >>what is the fundamental difference (or
>> >>improvement?) between OSPF and IS-IS?
>>
>> >>Bin Liu
>>
>>Several people mentioned my paper from 1991, and since it will
>>probably be hard to get (I don't have a copy, and haven't seen
>>it in years), I thought I'd mention it's probably not worth
>>worrying about. I'd be surprised if it would
>>be too helpful today. Both protocols have changed since then, so I'd think
>>the paper would be mostly interesting, if at all, for historical reasons.
>>
>>So back to "what is the difference between OSPF and IS-IS?"...
>>
>>This sort of question should be asked more often, especially where there
>>are "foo" vs "bar" debates. As I said in my "Miss Manners meets the IETF"
>>talk, unfortunately such questions often lead to err..nontechnical
>>responses. I'm glad that all the responses to this note have been
>>thoughtful and technical.
>>
>>And since people will periodically wonder about the real technical
>>differences between foo and bar, it is useful to write the stuff down.
>>
>>This particular question (differences between IS-IS and OSPF)
>>is a topic that is asked about sufficiently often that it would
>>probably be worth writing an updated paper, based on the most recent
>>versions of the two protocols. My book (Interconnections) discusses
>>some more differences, and Dave Katz's presentation is also
>>helpful. But I think it would be nice to have some set of people
>>carefully compare both specs, and
>>calmly write down the differences and the pros and cons of the differences.
>>And given that it seems like both protocols will persist, if there
>>are cases where one scheme is significantly
>>better, it ought to be folded into the
>>other protocol if possible.
>>
>>As people on the list have pointed out, there is a lot of similarity between
>>OSPF and IS-IS. To understand why there are two protocols, it helps
>>to know some of the history.
>>
>>Basically, the first link state protocol was for the ARPANET. It
>>introduced the idea of link state protocols, with the major
>>ideas being:
>> . flood link state information to everyone
>> . use Dijkstra's algorithm on the link state database to
>> compute paths
>> . an algorithm for incrementally updating the Dijkstra tree
>> when there are just a few link changes.
>>
>>The improvements (that I can think of off the top of my head)
>>introduced by IS-IS were:
>> a) making link state distribution robust (the ARPANET had an amusing
>> failure mode)
>> b) efficient incorporation of LANs, including the concept of Designated
>> Routers, LANs as pseudonodes, and link state syncronization over
>> a LAN using CSNPs. (ARPANET was just point-to-point links)
>> c) exchange of parameter information (such as how long to wait before
>> declaring neighbor down), so that parameters can be set independently
>> and differently, and still interwork
>>
>>IS-IS was originally designed for CLNP, which had two forms of routing:
>> . exact match of bottom 6 bytes, or
>> . shortest prefix of top part
>>That's where the "two levels" came about, though the "area routing"
>>stuff could in theory be multilevel. IP only has one type of routing, which
>>is like the shortest prefix, area routing in CLNP.
>>IS-IS would have looked a little different if it had originally
>>been designed for IP.
>>
>>OSPF was designed specifically for IP and was loosely based
>>on IS-IS. At the time OSPF was beginning
>>to be designed, it didn't occur to anyone that IS-IS could be easily
>>adapted to route
>>IP. Ross Callon noticed that once a routing algorithm existed, it was
>>a mere detail to add reachability information for a different data
>>packet format, and he wrote RFC 1195. (Interestingly, the concept
>>of integrated routing wasn't a new idea. I realized years later, when
>>looking at RIP's packet format, that RIP, deployed years before
>>integrated IS-IS was conceived, was designed for routing multiple
>>address families).
>>
>>Perhaps if the idea of using IS-IS for IP was thought of before
>>work on OSPF had started, there wouldn't be two protocols. But once
>>a group starts on something it's hard to stop. So there wound up
>>being two protocols.
>>
>>NLSP was a version of IS-IS for IPX, and introduced some improvements,
>>my favorite being DR election (see below).
>>
>>Differences I can remember (off the top of my head).
>>
>>a) Designated Router election: it's "deterministic" in IS-IS, which means,
>> given the same set of routers, the same router will be elected. It's
>> "sticky" in OSPF, meaning that once you get to be DR, you stay DR.
>> This makes things more stable...if the highest priority router is
>> flaky in IS-IS, every time it goes up it takes over, only to crash again.
>> But I was told when designing IS-IS that determinism was important, which
>> requires the behavior in IS-IS.
>>
>> For DR election, if I had to choose between OSPF's way and IS-IS's
>> way, I'd choose OSPF's way, but NLSP (IS-IS for IPX plus
>> some improvements) had a method
>> that gave the best of both worlds.
>> It has nodes change their priority after becoming DR,
>> which allows you through astute priority settings, to
>> choose deterministic or sticky behavior, or anything
>> in between.
>>
>>b) LSP distribution on a LAN: IS-IS does it with CSNP's. OSPF with
>> explicit acks. I believe both ways are just fine.
>>
>>c) Originally IS-IS passed no upper layer information into areas, and
>> you just exited via the nearest level 2 router, whereas OSPF always
>> fed all information into the area so you could choose the optimal
>> exit point. Both have now been modified so you can choose any
>> point on the tradeoff between extra routing info and optimal routing.
>>
>>d) parameter synchronization: IS-IS allows neighbors to have different
>> values for things like Hello Timer, and still interwork.
>>
>>
>>So anyway, there are a bunch of little nerdy differences, some of
>>which might matter and some of which are just different because different
>>groups did them. For the ones that matter, mostly the protocols have
>>evolved to take advantages of features in the other protocol.
>>
>>I assume if there was an updated IS-IS vs OSPF document, someone would
>>have mentioned it in response to Bin Liu's post. So assuming there
>>isn't such, if someone wanted to try to do it, I (and I'm sure lots
>>of other people) would be happy to help.
>>
>>Radia



This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:53 GMT-3