Henk Smit wrote:
Politics: "In fact, a number of members in the OSPF working group feared that IS-IS would be preferred for "political" reasons, as part of a grand plan to convert the Internet to OSI correctness, even if that meant a complete disruption of the service."(1)
"There were also non-technical considerations. Many people felt that it was better that the IETF have complete control over the OSPF protocol design rather than depend on an ISO committee whose goals, namely to produce a routing protocol for the OSI protocol stack, were somewhat different."(2)
This is all history, and should not be a reason for you to pick one protocol over the other. The IETF has become what OSI was (and even worse). Right now there are active OSPF *and* IS-IS workgroups. The IETF can extend IS-IS as much as is needed.
That's just one way to see the world. The other way is that obviously a demand for one or the other reason exists for both protocols and since both protocols are used to haul IP data, it's better for IETF to try to make sure that both protocols are in a decent shape in terms of standardization and interoperability. ISPs are customers here and until the world converges on one protocol (if it ever will), their needs should be met. The reasons for the convergence not being trivial or high on the priority lists of many have been discussed in other threads. Observe that neither OSPF nor IS-IS working group has on its charter "political fight of the other protocol" as many people try to interpret the IETF landscape (this of course only mirroring the human tendency to label things as bad and good and watch wrestling instead of debates of deep technical content ;-). As Henk mentions, little good documentation exists although ISIS work has been done (much of it by a well known, leading company ;-) to scale the protocol. One of the goals of the working group I particularly try to speak for is to document this kind of work.
OSPF: Scales well when the Backbone/area/stub model is correctly implemented, otherwise with many routers in a single area, it can have a definite performance impact on routing convergence times. IS-IS: Is less sensitive to growth problems then OSPF.
Most ISPs run their backbone as one IS-IS area. (Because there are no inter-area routes from level-2 into level-1). This is not a public
statement, so don't hold me responsible. But I believe that in a cisco network, with MIPS based boxes and running dCEF, and enough BW (T1s or so) you can probably easily put a 1000 routers or more in one area. In that case you don't need to mess with areas. Is a 1000 routers in one network enough for you ? Again, don't build a 1000 router network and when it breaks come complaining. Please contact your cisco SE (or me) if you plan to do this. :-)
nobody doubts that you can have 1000 routers staying up in a stable network, just the convergence time when coming up and links flap is kind of rather ugly issue ;-)
OSPF: Is easier to implement and understand. It is more widely used, and supported amongst many vendors.
That is true. More documentation and more experience. Note, many router vendors have implemented IS-IS recently, or are working on it.
Here I jump in for Henk, I wouldn't say OSPF is easier to implement correctly & efficiently than IS-IS. Argument about documentation & experience is true of course but that's what the group is for, the better documented the protocol becomes, the better the chance it will survive long-term IMHO.
IS-IS: Is more arcane. Harder to implement and understand it's operation and behavior, and may not be supported on every router.
Mmmm, actually I think IS-IS is easier to troubleshoot and predict once you understand the basics.
I would say it boils down to the documentation question agian ...
Other References I have yet to review: "Interconnections: Bridges and Routers" By: Radia Perlman (ISBN: 0201563320)
Biased towards IS-IS. Maybe you should have read it. ;-)
great book, however the level of detail is sometimes scanty if you look for deep insight into the specific protocols. Radia is updating it though ... thank you --- tony, the other co-chair ;-)