Not to nit-pick, but one correction and a few comments: Let's start with OSPF: ... 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. This isn't true. Timers must be consistant between adjacent routers, not across the entire network. This means, for example, that you must change both ends of a point-to-point link at the same time or must change all of the routers on a common multi-access network at the same time. ... 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 ACKs should be smaller than the distributed LSA's, so the savings should be a bit better than 1/2... ... The means of repairing a level-2 (backbone area) parition is, to put it politely, completely fucked in the head. I'm not sufficiently familiar with how IS-IS works to know how it solves this problem. But I wouldn't describe the OSPF virtual link mechanism as "completely fucked in the head"; think of a virtual link as a tunnel used only by the routing system... ... There are some drawbacks to IS-IS: ... IS-IS uses an underlying traffic exchange which is based on OSI/CLNS. This introduces requirements for OSI addressing and CLNS implementation which are otherwise useless in an IP-centric network. IMHO, this represents a substantial bit of operational complexity (obtaining CLNS addresses, teaching operations/engineering staff how to use them and interpret them while debugging, etc., etc...) On a pragmatic note, though, the relative successes of IS-IS and OSPF in the large provider marketplace probably has more to do with the relative competence of the cisco's original OSPF and IS-IS implementors than anything else (only someone else who suffered through OSPF's growing pains way back in the 9.0-9.1 days can really appreciate this comment...) --Vince