nanog mailing list archives
Re: IGPs in use
From: "Howard C. Berkowitz" <hcb () clark net>
Date: Tue, 13 Oct 1998 10:01:07 -0400
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
Current thread:
- Re: IGPs in use, (continued)
- Re: IGPs in use Tony Li (Oct 13)
- Re: IGPs in use Ben Black (Oct 12)
- Re: IGPs in use Chrisy Luke (Oct 13)
- Re: IGPs in use Paul G. Donner (Oct 13)
- BGP as an IGP (Was Re: IGPs in use) Chrisy Luke (Oct 13)
- RE: IGPs in use Thom Youngblood (Oct 13)
- Re: IGPs in use bmanning (Oct 12)
- Re: IGPs in use Richard Irving (Oct 12)
- Re: IGPs in use Paul Ferguson (Oct 13)
- Re: IGPs in use Howard C. Berkowitz (Oct 13)
- Re: IGPs in use Tony Li (Oct 13)
- Scaling Existing IGP Administration (was) Re: IGPs in use Howard C. Berkowitz (Oct 14)
- Re: IGPs in use Henk Smit (Oct 14)
- Message not available
- Re: IGPs in use Henk Smit (Oct 14)
- Re: IGPs in use I Am Not An Isp (Oct 13)
- Re: IGPs in use Paul G. Donner (Oct 13)