Peering Policies and Route Servers

Michael Dillon michael at
Tue Apr 30 20:50:05 UTC 1996

On Tue, 30 Apr 1996, Justin W. Newton wrote:

> This is a chicken and egg scenario.  If CompanyX could get to everywhere
> without buying a link to an upstream as well as their connection to the MAE,
> well, then they wouldn't buy the connection to the upstream provider.  The
> real point should be that losing connectivity to all whopping X,000 of their
> customers where X is between 1 and 9 is really not all that big a deal,
> netwise.  

Not true. It is a VERY big deal if too many blocks of X,000 sites are not
globally reachable because it would destroy the image of the Internet as a
single cohesive network aka "the Net" withe the emphasis on the word
"the". And I think peering agreements based on a handshake will always be
viable in the global Internet. It's not like other businesses. The net is
"real-time" in your face stuff that customers expect to be working on a
7/24 basis. There isn't any room for weasel words and slimy dealings.

Remember that there are folks like Bob Metcalfe who would dearly love to
see the global Internet to move to a settlements based system in which
every byte is charged a fee for transport because that would involve
installing the infrastructure that would make micro-money transactions
possible. See his current InfoWorld column which I found
incredibly vituperative. This man clearly has a grudge against one or more
Internet operators.

I don't believe it is in anyone's best interests, not even Metcalfe's or
3COM's, to have the huge recordkeeping and billing bureaucracy that would
be needed to do micromoney, even though I could personally earn a lot of
money by selling my written works that way. In the long run we are better
off pushing the network infrastructure into the noise that we don't even
care about paying for on a daily basis like your basic phone service or
the roads and highways infrastructure.

If we want to get to that point, we need to help along the small players
all we can. Sometimes it involves "tough love" like Sprint's route
filters, sometimes it is just sharing information on lists like this and
the IETF lists or at meetings like NANOG or IETF.

Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-546-3049                             E-mail: michael at

More information about the NANOG mailing list