IGP Comparison (Summary of Responses)
prz at dnrc.bell-labs.com
Fri Jan 8 17:46:39 UTC 1999
Henk Smit wrote:
> > Politics:
> > "In fact, a number of members in the OSPF working group feared that
> > would be preferred for "political" reasons, as part of a grand plan
> > convert the Internet to OSI correctness, even if that meant a
> > 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
> > rather than depend on an ISO committee whose goals, namely to
> produce a
> > routing protocol for the OSI protocol stack, were somewhat
> 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
> 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
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
interoperability. ISPs are customers here and until the world converges
protocol (if it ever will), their needs should be met. The reasons for
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
many people try to interpret the IETF landscape (this of course only
human tendency to label things as bad and good and watch wrestling
debates of deep technical content ;-). As Henk
mentions, little good documentation exists although ISIS work has been
(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
> network, with MIPS based boxes and running dCEF, and enough BW (T1s
> 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
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,
> > 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
& efficiently than IS-IS. Argument about documentation & experience is
of course but that's what the group is for, the better documented the
becomes, the better the chance it will survive long-term IMHO.
> > IS-IS: Is more arcane. Harder to implement and understand it's
> > 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 ...
--- tony, the other co-chair ;-)
More information about the NANOG