Let us all bend over, apply the Vaseline...

Michael Dillon michael at MEMRA.COM
Sat May 3 19:49:18 EDT 1997


On Sat, 3 May 1997, Jon Lewis wrote:

> On Wed, 30 Apr 1997, Michael Dillon wrote:
> 
> > Any ISP that can afford a multihoming-capable router and 
> > two upstream Internet connections should have no problems with 
> > $2500/year for their portable address space. As you point out, it's a mere
> > drop in the bucket, 30 cents per year per host address.
> 
> Are you sure of that?

Actually, no I'm not. If you have any hard facts to show the contrary,
then I'd like to hear them. 

> Do you run an ISP trying to scrape together the
> money to multihome?  Do you sit around at night wondering if it's worth
> trying to hack together a BGP router with a P100 and ET cards or just wait
> until you can afford a 4500M or better?

No, although have consulted with ISPs trying to make this discussion
including my former partners in the ISP business. So far, everyone I have
talked to has been able to make a business case for spending the money to 
buy or build a multihoming capable router.

> > Most ISP's will not be multihoming, therefore will not need
> > portable address space and therefore, most ISPs will not be paying this
> 
> Most ISP's in what time period?

Let me answer your other question first.

> I personally think that if the telco's
> and other giants ever get serious about providing internet service with
> clues, many (but certainly not all) smaller ISP's will be unable to
> compete.

That's a lot of ifs. Many people feel that it is simply not possible for a
large company in any industry to maintain a high enough clue level to
compete for very long against smaller entrepreneurial companies. I tend to
agree with this. However I also agree that smaller ISPs that do not have a
clue will be unable to compete with anyone.

> Those that do stay in business will require the reliability of a
> multihomedmed internet connection.

I used to think that most ISPs would become multihomed but as I've watched
things evolve over the last year and a half, I'm no longer so certain that
this will happen or that it will be necessary. Multihoming is only one
part of the redundancy equation in which an ISP strives to make sure their
connectivity into the global Internet is redundant enough that no single
point of failure can cut them off completely. The idea is that having
multiple backbone providers protects you from screwups by any one of them. 

However, things are not so simple. On the one hand, the large backbones
are working towards fully meshed networks with failover capabilities so
that the loss of a connection or a router will not cut anybody off.
They're not there yet but they are headed in that direction and I have no
doubt they will arrive. At the same time there are smaller backbone
prividers and regional providers who are building multihomed networks in
order that their downstream customers will not be cut off if a single
major provider goes down or if a single fault occurs within the regional
provider's network. Quite often these regional providers will supply their
ISP customers with a backup connection, either a second T1 or a frame
relay or ISDN circuit. This can even protect you from local backhoe
activity if it is engineered carefully.

So I think that in the grand scheme of things, multihomeing is less
important for the smaller ISPs than redundancy. And there are many ways in
which good redundancy can be deployed without multihoming. If you look at
the typical pyramid found in most industries, i.e. a few large companies, 
many mid-size companies and a ton of smaller companies, then I think I am
referring to the ton of smaller companies when I say that most ISPs will
not be multihoming.


Michael Dillon                   -               Internet & ISP Consulting
http://www.memra.com             -               E-mail: michael at memra.com

The bottom line is track record.  Not track tearing.  Not track derailing.
But pounding the damn dirt around the track with the rest of us worms.
       -- Randy Bush





More information about the Naipr mailing list