[8714] in Commercialization & Privatization of the Internet
Re: NAP philosophy & IP technology
daemon@ATHENA.MIT.EDU (Pushpendra Mohta)
Wed Dec 1 12:38:25 1993
From: pushp-m@cerf.net (Pushpendra Mohta)
To: fair@apple.com (Erik E. Fair)
Date: Wed, 1 Dec 1993 09:38:10 -0800 (PST)
Cc: com-priv@psi.com
In-Reply-To: <8519.754747357@apple.com> from "Erik E. Fair" at Dec 1, 93 04:02:37 am
Erik E. Fair writes:
>>
>> 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?
Regionals will do one or both. NSF proposed to fund only of these
options. For a copy of the solicitation and other questions and
answers, connect via gopher to gopher.cerf.net and look for
Network Service Providers for the NSFNET and NREN(SM)
>>
>>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).
Like you say, there are issues in routing over large clouds, but
when ATM/SMDS clouds from different providers connect
transparently, I suspect this will be the model.
--pushpendra
Pushpendra Mohta pushp@cerf.net +1 619 455 3908
Director of Engineering pushp@sdsc.bitnet +1 800 876 2373
CERFnet
