[8710] in Commercialization & Privatization of the Internet
Re: NAP philosophy & IP technology
daemon@ATHENA.MIT.EDU (Erik E. Fair" (Your Friendly Postm)
Wed Dec 1 07:03:08 1993
From: "Erik E. Fair" (Your Friendly Postmaster) <fair@apple.com>
In-Reply-To: <199311302005.NAA13566@goshawk.lanl.gov>
Cc: com-priv@psi.com
Date: Wed, 01 Dec 93 04:02:37 -0800
Date: Tue, 30 Nov 1993 08:27:11 -0600 (EST)
From: Stephen Wolff <steve@mon.cise.nsf.gov>
"To qualify for NSF support for NSP attachment and/or for the
provision of interNAP connectivity, a regional network must
attach to an NSP that connects all NSF-specified priority
NAPs." - NSF solicitation 93-52
[I presume NSP = Network Service Provider]
Now I'm confused about the new NSF connectivity model. Does a regional
network (e.g. BARRNET) connect directly to a NAP and then negotiate
peering arrangements with the other NSPs attached there (one or more
of which will be inter-NAP transit NSPs which connect to all other
NAPs), or does the hypothetical regional connect to another, bigger NSP
that will take it to all the NAPs? Or either/both?
I got a note from Milo which suggested "route servers" for other
routers from the different NSPs on a FIX-type LAN to simplify
configuration. After I thought about that, and about the interesting
behaviors I've seen from Cisco's BGPv3 implementation on the CERFNET
SMDS cloud that we're attached to, I think that notion will work: Start
with a very large cloud (e.g. nation-wide or international SMDS), with
each of the regional NSPs attached to that cloud with their router(s).
In principle, there is no reason why there can't be multiple providers
of "cloud" service, provided none of them are involved in the IP
routing over the cloud (to make it clean, everyone on the cloud should
be able to speak "directly" to everyone else without IP-visible
intermediaries or extra-hop weirdness) - they just do inter-cloud
routing (what would be, from the IP point of view, the MAC-layer), and
that leaves the NAPs as route servers on the cloud; just peer with the
one(s) whose policy you like.
Hmmm. On the other hand, I suppose that's solving the routing problem
by making it someone else's problem (TPC's).
Milo also mentioned that FIX-WEST is a combination of FDDI and Ethernet,
with the players who have FDDI also having Ethernet (i.e. hooked to
both the FIX-FDDI and the FIX-Ethernet), so as to avoid having a single
FDDI-to-Ethernet router (this preserves the full set of possible
peering arrangements for the NSPs on the FIX).
Yakov Rekhter opines that a single backbone is impossible to construct,
politically, because of the plethora of players. Peter Ford and Steve
Wolff seem to agree with him.
I still think that our network & transport protocols are telling us
that we want a single backbone for lots of reasons, and therefore, we
ought to keep trying to have one, rather than give in to pressures from
those who wish it were otherwise. I seem to remember NASA ignoring
warnings from some engineers once a few years ago, with spectacular
results. I'm not trying to say that the Internet will fail if we don't
build a single backbone - just that it will not work as well as it can
and should.
Erik E. Fair apple!fair fair@apple.com
P.S. If a multiple-backbone situation is going to be the future,
someone (NSF? DARPA?) should throw some money at Dave Mills for
development of a transport protocol (probably a TCP option or
two) that can deal with wildly different delays on the two
paths between a pair of peers. I think with his excellent work
on NTP and the HELLO routing protocol, this would be simple...
Does TP4 have a better answer to this problem than TCP?
