Steve,
It appears that you have inadvertently reopened the 'proverbial can of
worms'. ;)
This issue has been hashed and rehashed many times on this and other lists.
Rather than venture down that path again, I will voice my own humble opinion
as succinctly as possible. Note that I refer to Integrated IS-IS by simply
IS-IS.
IS-IS and OSPF are as similar as they are different. We can talk about
convergence speed, configuration complexity and flexibility, bredth and
depth of deployment, and so on. The real things to consider are easily
summarized. Again, this is my own humble opinion.
IS-IS is more easily extensible. This is because any new information that
needs to be carried is done so by way of a new TLV (or Sub-TLV) depending on
the information added. With OSPF, you need to create new LSA types.
IS-IS is also easier to understand in some ways. You have an LSP, it
originates from IS x, and it is easily verified. OSPF is similar, but there
are many different types of LSA's.
Perhaps the biggest strength in IS-IS is that it is deployed in the largest
ISP networks, which represent the bleeding edge in routing protocol
implementation. As such, and certainly as of recently, IS-IS gets new
technology faster than OSPF.
OSPF, in counterpoint, has more configuration options, and to some, may be
less esoteric in that it is a native IP routing protocol. IS-IS requires
some understanding of CLNP, especially when troubleshooting bad adjacencies
(I'm sure someone on this list was happy to see ES-IS adjacencies formed on
L1 links with different area ID's between the IS's). It should be noted
that with dynamic hostname exchange, wide metrics, L2->L1 route leaking,
three-way handshaking, and >256 pseudonode support now in most modern IS-IS
implementations, many of the previously glaring inefficiencies of IS-IS have
been eliminated.
There are four important operational benefits to OSPF that IS-IS does not
address, which I think it should:
1) IS-IS does not support administrative tags. I have a half written draft
that proposes this - perhaps I'll finish it tonight... This is useful when
injecting routing information from other protocols into OSPF(IS-IS).
2) IS-IS does not support external information across L1 adjacencies (OSPF
uses NSSA's to support this type of leasking from an area into the
backbone). This means that external routes must be injected at L2, or that
the entire network run at least L1/L2 across all links where redistribution
is necessary. I suppose this is possible, but not very useful when trying
to minimize convergence time and resource utilization.
3) IS-IS does not support point-to-multipoint configurations. Thus, you
need to create ptp subinterfaces to provide full connectivity across NBMA
clouds.
4) You cannot run multiple instances of IS-IS on one box. This is a touchy
subject, however, and likely has to do with the fact that IS-IS tends to be
deployed mostly in ISP networks, and an ISP's internal routing policy should
be consitent. By segmenting an IS-IS database, this in theory would break
that requirment. However, using a separate IGP at the edge to, for example,
agregate and contain large IP address pools has benefits. This is more a
design issue than a protocol issue per se, but it is certainly relevant in
this regard.
Perhaps the best way to determine which one to use is which one you think is
easier to deploy and maintain. In all the discussions of IS-IS vs OSPF I
have been privy to, I have never heard someone say (with any meaningful
credentials and without any meaningful bias) that one protocol is vastly
better than another. We are not talking PUP vs BGP here, or even EGP vs
BGP. It is more like comparing peaches to nectarines. The one that is
fuzzy on the outside depends on which one you call a peach.
I think it best that you refer to the following archives for more
information, although I'm sure some of the usual suspects on this list may
provide more info. I think this is a good discussion; however some may have
grown weary of it by now. ;)
See the following:
http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html
http://www.cctec.com/maillists/nanog/index.html
There are some good discussions on IS-IS vs OSPF on both these lists.
HTH,
chris
PS
This was longer than I expected. Perhaps someone needs to publish this
debate again. I wonder if Dr. Perlman is up to the challenge of redoing
"The Great IGP Debate."
PPS
For good IS-IS documentation, see Jeff Doyle's "Routing TCP/IP", as well as
"Large Scale IP Network Design" and "Advanced IP Network Design", by Retana,
et al and Raza, et al, respectively.
If you have true grit, you can read ISO 10589, as well as RFC 1195. There
is also a book by Martin, "DECnet Phase V". For a historical read, you may
wish to peruse the original DECnet Routing Protocl V2 Spec at
ftp://gatekeeper.dec.com/pub/DEC/DECnet/PhaseIV/index.html. The GARRNet
project in Italy has some useful information on IS-IS in respect to CLNS.
There are also some good papers on the SONET Interoperability Forum website,
which detail the use of IS-IS on the SONET DCN. If you don't understand
IS-IS by then, well then it looks like the decision is easy.
> -----Original Message-----
> From: Steve Lilley [mailto:slilley@thrupoint.net]
> Sent: Wednesday, September 06, 2000 10:58 PM
> To: Cisco NSP List
> Subject: [nsp] Advantages of IS-IS over OSPF
>
>
> Is there some advantage that IS-IS offers over OSPF for ISP
> backbones? I can't find anything documented...in fact, I can find
> VERY little documentation on IS-IS. This is quite a contrast to
> OSPF, where there is actually more information than I could ever
> want! :-)
>
> >From what I can tell, the biggest advantage for IS-IS is the fact
> that the backbone area is more flexible than OSPF's area 0. With
> IS-IS's two-tiered approach, the backbone can "snake" around the
> network easier than OSPF's area 0. Beyond that, I don't see many
> advantages. Since IS-IS is multiprotocol by design, it may
> initially support newer non-IPv4 protocols (i.e. multicast, IPv6,
> etc.) before OSPF, but that won't be tolerated for long by the
> huge number of OSPF customer's out there!
>
> As always, and feedback is appreciated!
>
> Regards,
> Steve Lilley
> ThruPoint
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:16 EDT