IGPs in use

Sean M. Doran smd at clock.org
Wed Oct 14 09:22:00 UTC 1998


| > most large nsps use is-is, but usually only to carry the routes of the bgp
| > speaking interfaces.
|
| Really?? Not that I desire to express any prejudices, but I honestly
| thought nobody used it.

Everywhere that Peter went...

It wouldn't surprise me to learn that everywhere that Andrew went
does it too.

| Does it just work better for very large networks?

"Better" is difficult to nail down.  It works acceptably.
Few people have the experience of switching from one to the
other with networks the size that they are today, and probably
only they are in a position to make that kind of qualitative
judgement.

While IS-IS and OSPF are really similar, and Dr Li was right
that on a theoretical level they both ought to scale the same
way, since they are both two-level IGPs, there are some
fundamental differences which may hurt during failures and
may hurt going into the future.

Let's start with OSPF:

The per-neighbour state in OSPF is large.  

The lifetime field counts upwards (I have heard this decision was
made just because IS-IS counts downwards).  This turns out to be
dumb: you can't increase the refresh interval, so dumping a full
routing table into OSPF means you have to refresh one LSA every
30ish milliseconds around the clock, assuming you don't have any
other instabilities, and before considering adding extra data (like
AS paths) and the multiplicative effects of flooding across NBMAs
and the like.  Since we count upwards, we cannot reduce the refresh load.

Timers must be consistent among all neighbours, so if you want
to make a change to your hello/dead timers to deal with delays
somewhere (in links or routers), then you have to configure
your entire network all at once.

The "scaling" feature of multicasting on a multicast-capable
subnet saves you only 1/2 of your traffic, and LSA traffic still
grows as your neighbour count grows.  This is thanks to the unicast ACKs.

The means of repairing a level-2 (backbone area) parition is,
to put it politely, completely fucked in the head.

Because OSPF was designed to be "really fast" on machines with
32-bit register operations, everything is beautifully 32-bit,
which is not the greatest in terms of granularity.  One of the
sacrifices were fields that might let one extend the protocol,
other than adding new LSA types.  Whee!

IS-IS on the other hand is considerably more extensible.
The existence of integrated IS-IS for IP is a pleasant
demonstration; the work by Henk Smit of Cisco also underlines
how IS-IS can be brought forwards towards the future.

Unlike in OSPF, IS-IS LSP traffic is constant independent
of neighbour count.

The LSP refresh timer is down-counting, and so you can make
the refresh interval as long as 18 hours.  This is good, because
when you have a stable network, you might not want to fill it
with unnecessary LSPs.

The hello and dead timers are independent of each other -- you
can tune them in parts of your network, rather than needing to
tune them everywhere in your network all at once.

The per-neighbour state in IS-IS is quite small.

There are some drawbacks to IS-IS: its per-link metrics are not
rich as currently defined, the LSP space is limited (but can be
hacked at), and you are stuck with no more than 255 pseudonodes.
All of these are likely to be hacked at and some seem pretty 
fixable by locking Henk and Tony (and probably Dave Katz, who did
a good public analysis of IGP scaling at NANOG in Phoenix and who
has done even better private analyses and gripefests --:) ) in a
room for a few hours.

Of course, as the number of vendors developing IS-IS grows,
it too may develop fun change control issues, but it's unlikely
that many changes will be made that will lead to a lack of
interoperability with previous (or other) implementations.
Doing it in the IETF (as with BGP) is probably not so bad an idea, either.

Frankly, though, I'm hoping that rather than locking themselves
in the room to "improve" IS-IS, the Obvious People lock themselves
into a room and build something else instead (which they might simply
call IS-IS, even if it isn't.  Been there, done that, called it BGP).

None of the current IGPs is free of bad scaling problems
and building one that is will be hard, so don't get
ready to throw out your iBGP hacks yet.

	Sean.



More information about the NANOG mailing list