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