update on transition from the NSFNET Backbone Service

epg at merit.edu epg at merit.edu
Mon Oct 3 22:06:14 UTC 1994


	Status of NSFNET Transition
            30 September 1994	

Merit's agreement with NSF for the transition from the
current NSFNET Backbone service to the new NSFNET program
has two phases; one which terminates on 31 October 1994
and the second which terminates on 30 April 1995.  The goal
of the first phase is to migrate all possible regional networks
and other network providers to the new NSFNET program architecture.
The final phase will likely continue to provide for some service to
supercomputing centers until the vBNS comes on line.  The NSFNET backbone
service will be discontinued in its entirity by the end of April 1995.

Due to numerous dependencies, some technical and some administrative,
none of the regionals have established solid alternatives to the
current NSFNET backbone service as of September 30, 1994. 
While Merit had anticipated retiring ENSSes and terminating
backbone service to some regionals by October 31, 1994, that does
not seem feasible at this point.  Merit anticipates that it will
maintain NSFNET Backbone Service to the regionals until the
end of November as the regionals establish stable alternatives
to the current service.

The NSFNET Backbone Service transition to the new NSFNET Program
has several dependencies and associated tasks. The tasks which
must be accomplished prior to moving any of the regionals off
of the NSFNET Backbone Service are:

1) establishment of three priority NAPs
2) attachment of the NSFNET Backbone Service to the three priority NAPs
3) attachment of NSPs which provide service to the NSF
regionals to the three priority NAPs
4) development of the Routing Arbiter Service, including the
establishment of Route Servers at all four NAPs and a Routing Registry
5) attachment of the regionals to an NSP

1) establishment of three priority NAPs

The nap-info at merit.edu mailing list has been established to field
questions from organizations or individuals concerning the services
being offered by the four NAP providers.

The Sprint NAP is now considered operational for purposes of the
NSFNET Backbone Service transition.  Sprintlink, MCInet and the
NSFNET/ANSnet services are all physically present on the Sprint
FDDI NAP.  The NSFNET Backbone Service is peering with the routers
of the MCInet service.  A session with Sprintlink services
is scheduled to be established in early October. Currently only test 
traffic is being exchanged.

PacBell has come to agreements with MCInet and the NSFNET Backbone
Service, and both MCInet and NSFNET/ANSnet expect to be physically
present at the PACBell ATM NAP by the first week of October.

Ameritech continues to negotiate with the NSPs.

Whereas MFS is not considered a priority NAP, MFS's MAE-East facility
is undergoing an upgrade from a distributed Ethernet to a colocated
FDDI ring at the MFS Gallows Road facilities.  Sprintlink and MCInet
are both physically present at MAE-East and will upgrade their
connection to FDDI.
 
2) attachment of the NSFNET Backbone Service to the three priority NAPs

The NSFNET backbone service was physically connected to the Sprint
NAP on September 13, 1994.  Physical connection to the PacBell
NAP is projected for the first week of October 1994.  The earliest
the NSFNET Backbone Service will be physically present at the
Ameritech NAP is November 1, 1994. 

The NSFNET Backbone Service is currently attached to the MSF MAE-
East interconnection. Alternet, which has generously funded that
connection, will terminate that support as of October 31, 1994. 
No provision has been made to continue the current NSFNET Backbone
Service connection to MAE-East.

3) attachment of the three NSPs which may provide service to the NSF
regionals to the three priority NAPs

ANSnet will have connections to the three priority NAPs coexistant
with the NSFNET Backbone Service.  The Sprint connection is  
in place as of September 13, 1994; Ameritech is still being 
planned; and PacBell is projected for the week of October 3. 
ANSnet is also a CIX member and has access on MFS's MAE-East
as part of the NSFNET Backbone Service until October 31, 1994.
ANSnet has a MAE-East connection for an MBONE router independent
of the NSFNET Backbone service attachment.

MCInet has been physically present at MAE-East since August 15, 1994.
MCInet has applied for membership in the CIX. The connection to
the Sprint NAP was completed the week of September 12, 1994.
Attachment to the PacBell NAP is projected for September 29, 1994.
No date has been set for the attachment to the Ameritech NAP.

Sprintlink was physically present at the Sprint NAP as of the week of
September 19,1994. Sprintlink is a member of the CIX and is
connected to MFS's MAE-East. Sprintlink has no firm date for
when it will connect to the PacBell and Ameritech NAPs. 

AGIS, a new network service provider, has indicated that they
intend to connect to all four NAPs. We have not received further
information from AGIS since early August.

4)  development of the Routing Arbiter Service, including the
establishment of Route Servers at the NAPs and a Routing Registry

ISI/IBM has ordered the route server equipment and is negotiating 
access contracts with the NAP providers.  We have no firm date for 
connection to the NAPs at this moment; however, the RA team anticipates
that the route servers will be in place by the middle of October.

Merit has installed the RIPE routing registry code and has collaborated
with the RIPE NCC on new objects and attributes which will permit
the description of more complex routing requirements.  The
Routing registry (based on RIPE 81) is available for use.  
With the adoption of RIPE 181, Merit is in the process of
migrating the current routing registry and the PRDB to RIPE 181
format.  Merit will be publish the migration plan as soon as
it is finalized.

The Route Server software development for initial release 
has been completed and in undergoing testing and debugging.
Preliminary testing of route servers was conducted at the networks and
infrastructure laboratory at USC.  A network of 8 SUNs on a LAN were
used to simulate a NAP environment.  Two of these were used as route
servers, and the other six were used as NAP clients producing and
consuming routes.

The route servers were tested for correctness, fault tolerance,
resource utilization, and scalability.  Correctness, fault tolerance
and resource utilization tests were conducted in the infrastructure lab
environment.  Resource utilization and scalability predictions based on
micro-analysis of tests done in the lab are currently being verified.
These require feeds of a large number of routes from various sources on
the Internet.  They are being provided by Alternet, CERFnet, and ANS.

The initial release supports BGP4 over IPv4 with multiple views.
BGP4 MIB is supported and externalized through the ISODE SNMPv1
agent, which has been ported to SUN and is undergoing testing.

The RA team has begun generating prototype configuration files based 
on data in the routing registry for the route server. 
Questions concerning the routing registry may be sent to rradmin at merit.edu.

5) attachment of the regionals to an NSP

Only a few of the regionals that are currently served by the
NSFNET Bckbone Service have notified Merit that they are still
on schedule to transition to a new service provider by October
31, 1994.

They are:
BARRnet
Cerfnet
Midnet
MSC
NEARnet
NevadNet
NC-REN 
THEnet

NYSERnet has indicated, due to a complete reengineering of the
NYSERnet backbone, its transition will be complete around
December 15,1994.

Merit has hoped to terminate the service agreement with
ANS at several ENSSes by October 31, 1994, but this does not appear
feasible.  However, we do anticipate that regionals which will 
have completed the transition to a new provider by October
31, 1994 will cease to use the NSFNET Backbone Service  as
their primary service provider at that time.

The way Merit would like to proceed is:

1) each regional will project a date as to when they will have completed
attachment to a new service provider.

2) Merit will check with the regional approximately 15 days prior
to the projected date to confirm that the targeted date is still
realistic.

The purpose of this checkpoint is to confirm the state of the
new attachment and to determine the feasibility of issuing
a termination notice of the NSFNET Backbone service.

3) Depending on the regional's report, Merit will either issue
a termination notice to ANS or will revise the projected date
for attachment to a new service provider.

If a regional reports that the installation and testing of its 
new service is progressing satisfactorily and that the regional
is convinced that any risks associated with terminating the
backbone service are negligible, Merit will issue the
termination notice to retire the ENSS associated with the
regional.  This will be done in consultation with the regional
concerned. If more than one regional is serviced by an ENSS,
each of those regionals must have acknowledged the issuance of
the termination notice.

In addition to the previous plan, Merit is continuing to investigate 
ways to downsize the NSFNET Backbone Service without disrupting the 
stability of network connectivity to the NSF community.

It appears that there are three potential ENSSes which may be
potential candidates for retirement according to the stated
plan. If these organizations are on target with their projections,
the termination notices for their ENSSes may be issued around
October 31, 1994.

ENSS 128	BARRNET(AS 199,200)

ENSS 134	NEARnet (AS 3, 560, 701)

ENSS 142	Westnet (Utah - AS 210)A

These three organizations seem most likely to succeed in 
establishing attachment to their new service providers by the end of
October and that will result in the ability to retire ENSSes.
The ENSSes associated with those organizations will
probably be retired as close to October 31, 1994 as possible.

Due to the fact that there are two ENSSes at College Park and
that the MAE-East connection will be eliminated by October
31, 1994, it may be possible to consolidate the traffic
at College Park to one ENSS.  Therefore, we are investigating 
the possibility of retiring ENSS 136 as close to October 31, 1994
as possible. 

Organizations which have indicated which service provider
they have chosen for inter-domain connectivity are:

Netcom		ANS
PREPnet		ANS

BARRNET		MCInet
CICnet		MCInet
MICHnet		MCInet
MIDnet		MCInet
NC-REN		MCInet
NEARnet		MCInet
NorthWestNet	MCInet
Sesquinet	MCInet
SURAnet		MCInet

MSC		Sprintlink
NevadaNet       Sprintlink
NYSERnet	Sprintlink
THEnet		Sprintlink
WESTnet		Sprintlink

Organizations that continue to offer independent service are: 

Alternet
DANTE
DISA
DREN
ESnet
ICM
Milnet
NSI
PSI

We are still waiting for the confirmation of plans by the other
organizations.

It is the NSF sponsored regionals which must be satisfied
with the stability of their new connections before any
action  is taken to remove the NSFNET service to those
regionals. We anticipate that many organizations will have
completed their transition well in advance of any formal 
removal of the NSFNET backbone service.  

The establishment of the vBNS is the final element in the
transition plan from the current service to the new NSFNET
program.  The supercomputer centers are beginning to investigate
ways to migrate their commodity traffic to alternative providers.

MCI has indicated that its target is to have an operational
vBNS service in place approximately 6 months after signing the 
cooperative agreement.  We have had no update on the state of
this activity.





More information about the NANOG mailing list