The "IGP's in use" thread is diverging into several interesting subthreads,
so I thought I'd start changing the title. There seems to be one thread on
requirements/properties of a future IGP that Does The Right Thing: Sean
Doran eloquently commented, in respect to something based on IS-IS,
Frankly, though, I'm hoping that rather than locking themselves
in the room to "improve" IS-IS, the Obvious People lock themselves
into a room and build something else instead (which they might simply
call IS-IS, even if it isn't. Been there, done that, called it BGP).
May I propose a name for this? IS-IS's New Technology, or ISNT? As a
followon to the T-shirt "IS - IS = 0" this could be "It ISNT IS-IS".
My focus in this subthread is working with what we have now, a somewhat
different emphasis. A rough example follows.
hcb@clark.net (Howard C. Berkowitz) writes:
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,
Yes, those sound like a list of administrative nightmares. 
Or a lucrative dream for the right sort of consultant? 
[not me!]
Wouldn't it be much easier to make use of a three or four level
hierarchical IGP?
As you'll see in the example below, is looking at this purely from an IGP
perspective the whole issue for ISPs? I've sketched out some
administration tools/procedures below that consider operational
requirements other than the routing alone.
No argument that it would be easier if everything were picked up
dynamically by a new protocol -- but I was focused on what is commercially
available now. As you've pointed out many times, static routes have a
distinct role at the edge (and other places).
Pending the deployment of more general hierarchical protocols, and
supporting mechanisms such as MPLS, I was trying to focus on short-term
things. My first law of network design is to try never to enter an address
more than once, and locally written scripts and simple programs can help
enormously with this.
I grant that one cannot assume the average enterprise necessarily has any
programming capability. Yet most ISPs and integrators do. I'd like to
throw out an example how some simple programming can minimize
administrative work. Obviously, there are higher-end packages that can do
some, but not all of this.
Consider the fundamental requirement to manage one's address space. Let's
say you are an ISP, and decide to offer /28 blocks to small customers, with
a /30 for single-homed connectivity to each of them. Initially, you plan
for 128 such customers, so you obtain a /21 for the small LANs and a /23
for the LAN access.
You have some number of edge routers that have a single active path to your
distribution/backbone level. By single active path, I include load-shared
links and on-demand backups.
The distribution tier routers do run a dynamic IGP and have multiple paths.
Assume you have four distribution routers servicing 32 users, so the router
has a /23 for LANs and a /25 for WANs. Set up blackhole static routes to
each of these blocks, and redistribute them into the IGP.
A rough example follows. When you set up a new customer, have
scripts/programs that do the following:
1. Create a customer entry in your database (which might be a spreadsheet)
Capture:
the DLCI and physical serial interface ID of the customer's PVC
at the distribution router end
basic DNS information, such as the customer domain, the mail
exchanger, etc. You'll have string variables already defined
with your domain name, etc. Fill in standard host names if
desired, such as www.customerdomain.
2. Assign the next available /28 and /30. Create integer variables
with the prefix values of both: lanPrefix and wanPrefix
3. Assuming a single frame link between the core and distribution routers,
generate the statements, using an ipAddr function that outputs a string
containing a dotted decimal address for an input 32 bit integer:
! for the edge router
ip route 0.0.0.0 0.0.0.0 ipAddr(wanPrefix + 1)
! for the distribution router, which is redistributing static
ip route lanPrefix 255.255.255.240 ipAddr(wanPrefix + 2)
int s(whatever).DLCI
ip addr ipAddr(wanPrefix + 1) 255.255.255.252
! assuming you want DNS names for your router interface,
! generate for your DNS as appropriate...
<interface-name-convention> IN A ipAddr (wanPrefix + 1)
(wanPrefix + 1) IN PTR <interface-name-convention>
<interface-name-convention> IN A ipAddr (wanPrefix + 2)
(wanPrefix + 2) IN PTR <interface-name-convention>
! user router interface, using a convention of the router interface
! is the first host. I like to use a convention of it being the last.
<interface-name-convention> IN A ipAddr (lanPrefix + 1)
(lanPrefix + 1) IN PTR <interface-name-convention>
! MX record as appropriate
! user host records as appropriate
! generate access lists, access server commands, firewall commands,
! etc. as appropriate for your local policies.
4. Load the generated configuration statements into the appropriate
router config files. There are any number of ways to do this,
and your local policies will dictate whether you replace or merge.