North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IGPs in use

  • From: Howard C. Berkowitz
  • Date: Tue Oct 13 10:23:35 1998

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