Comments both on the historical tradition and on glass ceilings. Many master plumbes believe the First Law of Plumbing isn't "water runs downhill," but "If it don't leak, don't fix it." Part of the reason, as far as I can tell, that some of the oldest and largest NSP's use IS-IS is that IS-IS was the best IGP decision at the time they made the decision, and they have subsequently learned to tune it so well there is no obvious reason to change to a different IGP. Some newer IGPs use OSPF and are happy with it. Glass ceiling limits apply to both IS-IS and OSPF. Other startup NSPs were started by people who themselves started at one of the original ISPs, and used, at their new firms, the technology with which they were most familiar. Couple of practical reasons for the initial IS-IS choice. Remember, this was 1990 or so. Cisco's initial OSPF code had some problems that were fixed around IOS 9.1(8), but the NSPs were working with earlier code that had a more solid IS-IS implementation. Also, remember that the jury was still out if there would be a major market demand for OSI/CLNP routing. OSI was getting lots of publicity...this was a time when the Corporation for Open Systems had a technical staff of 140 programmers. IS-IS gave the NSPs flexibility to go either way. As to the glass ceiling, there is a place for everything and everything should be in its place. For those of you familiar with my desk, I refer to technologies here rather than physical surroundings! When I gave my OSPF tutorial at NANOG in June, I stressed OSPF shouldn't be thought of purely as a 2-level hierarchy with a routing domain consisting of an area 0 and a set of nonzero areas. Some of the OSPF scaling problems I see, and these are probably equally likely in IS-IS, come from people trying to put everything into a single OSPF routing domain. Aside from performance issues, this can become a network administration nightmare. Splitting the interior network into several IGP routing domains, and linking these with a backbone-of-backbones, helps both performance and administration. The backbone group doesn't need to be concerned with LAN installations in a POP or customer site. Depending on the particular network, you might link IGP routing domains with: -- static routes -- iBGP, putting all IGPs in a single AS -- iBGP and eBGP in a confederation -- Hybrid layer 2/3 techniques, such as linking IGP-routed domains to internal layer 2 "superhubs" How much IGP support you need will depend on your network. A large enterprise, or a provider of both connectivity and content, will probably need more IGP stuff than a pure connectivity provider. Howard

Randy Bush wrote about OSPF and IS-IS:

neither scale well.

Randy, would you like to explain to us what your criteria are ? How many routers, links, prefixes should one be able to put in one IGP ? How many in one area ? How much dynamics should an IGP be able to endure ? How much optimal routing are you willing to give up by using summaries to improve scalability ? Do you think it is acceptable to tune the IGP by user configuration (like laying out areas), or should the IGP be full-automatic ? Thanks in advance, Henk.