Test

Download

test@lists.nanog.org

October 1994

39 participants
51 discussions

update on transition from the NSFNET Backbone Service
by epg＠merit.edu 03 Oct '94

03 Oct '94

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(a)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(a)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.

1 0