| > 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.