Seriously, why do folks like it?  OSPF is far superior.  For those implementing IPv6, I don't want to hear any whining about ships-in-the-night routing and precious router memory.  Modern routers have more than enough…

Anyway, here's my list of issues with IS-IS:

Too many TLVs!

It's all very wasteful by default.  For example, TLV types 128 and 130 carry IP address/netmask data with narrow (6-bit) metric values.  TLV 135 (extended IP reachability) does the same thing, but with sub-TLVs and wide (24-bit) metric values.  Both are advertised by default in L1 and L2 areas, and.. get this, as a result, TLV 135 is ignored.  Using JUNOS' wide-metrics-only directive suppresses all but type 135.  However, as 135 has no Internal/External bit, L1/L2 routers advertise L1 routes into L2 areas since they are seen as all internal.  The Up/Down bit saves us from loops, this time!  Anyway, Joseph M. Soricelli states on page 184 of the JNCIS: Juniper Networks Certified Internet Specialist Study Guide (JNO-303):

The reason for the separate TLVs, as well as the history behind their use, is outside the scope of this book.

I bet it's politics as usual.

Route Leaking

In IS-IS, external L1 routes aren't advertised out of the level, at all!  The L1/L2 routers won't do it, by default, unless you configure route policies to leak the routes out into the L2 area.  Using wide metrics will accomplish this, too.  The default just seems silly, though.. OSPF has no problem with this!  An ASBR in a non-backbone transit area sends out a type 5 LSA with is spread through the whole OSPF network.  Even stub areas (well, NSSA) support this with type 7's that are translated to 5's at the ABR.

These types of limits just seem unnecessary, to me.

MTU of 1492

All links that run IS-IS must support a minimum of a 1492 byte MTU.  Why are we stuck with this archaic limit in this day and age?  More and more tunnels, VPN and other, are being used in enterprise and service provider networks, and may not be able to accommodate this requirement.

Furthermore, the method that IS-IS determines whether a link is capable of 1492 is fairly humorous, and wasteful.  Each Hello PDU is padded with type 8 TLVs, which add on chunks of data (255 bytes per TLV) to reach 1492 bytes.  If the link doesn't support 1492, the Hellos are dropped and an adjacency isn't formed.  This just seems wasteful, to me.  Fortunately, JUNOS supports "smart" padding so such TLVs are only included until the adjacency comes up.  I don't know about IOS, though.

Vestigial Metrics

I suppose vestigial is the wrong word to use, since NO router vendor has EVER implemented them.  I'm referring to the delay, expense, and error metrics (1 wasted byte, each) in TLVs of type 128 and 130.  For those who say OSPF is "chattier" than IS-IS, these wasted bytes add up!

802.3 LLC

IS-IS on an Ethernet network uses the 802.3 w/LLC frame type instead of a more normally-used Ethernet-II type w/a unique ethertype.  I suppose this is a result of DEC developing the protocol so it could be used with DECnet phase V, which supports ISO addressing (see next section).

NSAP Addresses

NSAP addresses (ugly things like 49.0001.0101.0000.0003.00) are used for router identification, as a result of IS-IS being built around the OSI stack.  These addresses are cumbersome to work with, and really have no place in IP or IPv6 networks.  Although, many telcos still deploy services using CLNP with IS-IS, so I guess this makes sense for them.

Default Routes

Since L2 routes aren't advertised into L1 areas, a default route (::/0 or 0/0) is used to reach destinations outside the L1 area.  The L1/L2 routers set the attached bit in the TLVs they send into the L1 area, and the L1 routers generate default routes pointing to the nearest L1/L2 router.  Why do we have to rely on default routes to reach destinations in our own administrative domain?  It just seems like a bad design, but does cut down on database size.  The equivalent of this is a stub area in OSPF, which is only used if old routers (limited on memory) are used.

Address Summarization

Unlike OSPF, where the address summarization just plain sucks, IS-IS doesn't do it at all!  If you really want to do this in JUNOS, you just use aggregate routes and leaking.. eww.

So, anyway, I have yet to see a reason to use IS-IS over OSPF in any type of environment.  And if you're about to bring up ships-in-the-night again, new implementations of OSPFv3 should support both IPv4 and IPv6 without the need for v2, at all.  It's the best of both worlds!

New comments are currently disabled for this entry.