different thinking on exchanging traffic

Sat May 23 03:02:47 UTC 1998

> From: "Sean M. Doran" <smd at clock.org>
> Subject: Re: different thinking on exchanging traffic
> Date: 	Fri, 22 May 1998 17:38:12 -0700
> 	[...]
> Meanwhile, you might find the Sprint response to the NSFNET
> NAP solicitation ("National Virtual NAP") hanging around somewhere
> online.  You should read it and imagine why it didn't fly.

I believe that all four of the winning NSFNET NAP submissions proposed
nationwide "NAPs".  I believe that the reason they didn't happen is that
the NSF asked for and assumed it would get four geographically-focused
solutions.  I suspect that the notion of awarding four NAPs, all of which
covered all of the country, provided the NSF a certain amount of heartburn.
I believe that the nationwide NAP concept died, (or was killed), at the
time for administrative, not technical, reasons.  But, this is all
speculation on my part...

I have two conflicting notions about the the interesting possibilities
offered by nationwide layer-two services:

o	Layer-two services with distance-insensitive pricing, such as
	ATM, create some interesting opportunities.  If it doesn't cost
	any more to get across the country than to get across town, why
	should I build a local NAP rather than a nationwide NAP?  (Unless,
	of course, I am a RBOC and am administratively constrained from
	offering inter-LATA service.)  (I am also ignoring a comparison
	of a NAP-in-a-closet/POP/parking ramp versus a
	NAP-in-a-metropolitan-area; this is e-mail to nanog, not a
	paper for Sigcomm.)  Perhaps more relevant today, why should I
	build a regional Gigapop, _if_ my ATM pricing is truly
	distance-insensitive?  (There might be an answer to the last
	question, I really don't know.  But, I keep asking.)

	In other words, if pricing is distance-insensitive, why do I
	need local exchanges?

o	Distance matters.  It is easy to configure an IP network over
	a large layer-two service that bounces packets around the country,
	(because IP routing protocols generally think in terms of hop
	count, not [physical] distance).  It would be nice if
	routing protocols thought about [physical] distance, rather
	than require the network designer to be responsible for 
	designing the network such that considerations of physical
	distance were implicit in the network design.  Of course, in the
	good old days before distance-insensitive-priced services, this
	wasn't such an issue.

(I don't know whether there are very many copies of Sprint's "National
Virtual NAP" proposals hanging around.  I had to nearly sign my life
away to get a copy at the time...)

-tjs