- ripe-list - mailman.ripe.net

RE:
by jnolan＠dircon.co.uk 22 Apr '95

22 Apr '95

Alexander, One of the mysteriies of the Net!!! Regards John Francis Nolan ------------------------------------- All is flux, nothing is stationary 04/22/95 10:24:59

1 0

Re: Config Run on Sunday, April 23 1000EDT
by phuston＠nsf.gov 22 Apr '95

22 Apr '95

Let me add the appreciation of NSF to that from Elise to all of you who have been taking independent and proactive actions to help assure a smooth transition both for your regions and others. Thank you. Priscilla Huston At 10:19 PM 4/21/95, Elise Gerich wrote: >Merit has rescheduled the configuration run which was postponed on >Friday, April 21, 1995 for Sunday, April 23 at 1000 EDT. The originally >scheduled configuration window was postponed because the configuration >file for ENSS 147 (MAE-East) exceeded 17MB and was corrupt. We had >to allocate more filesystem space in order to generate a complete >configuration and in addition we worked with ASes 293, 297, 568, >1800 and 3561 to reduce the number of net lists contained in the >configuration file. The result is a configuration file of a more >reasonable size (9.9MB). > >The additional activity which was planned for April 21, 1995 was >to disable peering sessions between AS 690 and others at the following >ENSSes: >128 >129 >130 >131 >132 >133 >134 >135 >137 >139 >140 >141 >142 >143 >145 >This activity has been rescheduled for 0700 EDT on Tuesday, April 25, 1995. >Several organizations have taken the initiative to reduce their dependence >on the NSFNET Service even though we had to postpone the planned configuration >today. Thank you all for taking those actions independently. > > --Elise Priscilla Jane Huston Program Director of the NSFNET Program National Science Foundation Voice: (703)306-1949 or (713)527-4007 4201 Wilson Blvd Fax: (703) 306-0621 Arlington, VA 22230 Internet: phuston(a)nsf.gov or pjh(a)rice.edu

1 0

Config Run on Sunday, April 23 1000EDT
by Elise Gerich 22 Apr '95

22 Apr '95

Merit has rescheduled the configuration run which was postponed on Friday, April 21, 1995 for Sunday, April 23 at 1000 EDT. The originally scheduled configuration window was postponed because the configuration file for ENSS 147 (MAE-East) exceeded 17MB and was corrupt. We had to allocate more filesystem space in order to generate a complete configuration and in addition we worked with ASes 293, 297, 568, 1800 and 3561 to reduce the number of net lists contained in the configuration file. The result is a configuration file of a more reasonable size (9.9MB). The additional activity which was planned for April 21, 1995 was to disable peering sessions between AS 690 and others at the following ENSSes: 128 129 130 131 132 133 134 135 137 139 140 141 142 143 145 This activity has been rescheduled for 0700 EDT on Tuesday, April 25, 1995. Several organizations have taken the initiative to reduce their dependence on the NSFNET Service even though we had to postpone the planned configuration today. Thank you all for taking those actions independently. --Elise

1 0

POSTPONED - NSFNET configuration
by Elise Gerich 21 Apr '95

21 Apr '95

Due to the number off changes that had to be made in the configuraton files for Friday, April 21, 1995, some of the files grew so large that they would truncate during production producing corrrupt configuration files. At this time of the evening/morning we do not have confidence that we will be able to have complete and correct configuration files produced in time for the normal configuration window. We are thereby postponing the Friday, April 21 configuration until Saturday. This means that the discontinuation of the NSFNET service that was planned for Friday, April 21 at 0900 EDT is also postponed. We anticipate rescheduling the test for Monday, April 24, and will notify the community of more concrete plans by 1300 EDT on Friday, April 21. --Elise

1 0

The plan - April 21, 1995
by Elise Gerich 21 Apr '95

21 Apr '95

To better clarify which Autonomous Systems will be effected by the April 21, 1995 action, here is a list of the NSFNET Backbone Service nodes and the associated Autonomous Systems that will be disabled . These sessions will be disabled on April 21, 1995 at 0900 EDT. --Elise City ENSS# Associated AS# -------------------------------------------------------------------------------- Ann Arbor, MI 131 237 MICHnet 1225 CICnet Argonne, IL 130 683 Argonne 1225 CICnet Boston, MA 134 560 NEARnet 701 Alternet Boulder, CO 141 68 Los Alamos 278 MexNet 297 NASA 2648 NIST Champaign, IL 129 555 MSC 698 UIRnet 1225 CICnet College Park, MD (FIX-East) 145 293 ESnet 297 NASA 568 Milnet 668 DREN 2699 DSI 1800 ICM Houston, TX 139 114 Sesquinet 297 NASA 3354 THEnet Ithaca, NY 133 174 PSI/NYSERnet 133 gated testing Lincoln, NE 140 93 MIDnet Palo Alto, CA 128 199 BARRnet 200 BARRnet Pittsburgh, PA 132 204 PSCnet 1206 PSCnet Princeton, NJ 137 97 GES/Jvncnet 1250 Princeton Salt Lake City,UT 142 210 Westnet Seattle, WA 143 685 NorthWestNet 73 NorthWestNet San Diego, CA 135 195 SDSC 1740 CERFnet 1838 CERFnet 2150 CSUnet 22 NOSC NASA Ames, CA 144 200 BARRnet The following ASes will disable their sessions with the NSFNET Service and will reestablish it after a period of time. These ASes have advised us that the disabling of their sessions with the NSFNET between 0900 and 1000 EDT on April 21, 1995 will cause reachability and capacity problems. Champaign,IL 129 1224 NCSA 38 UIUC Pittsburgh,PA 132 3577 Prepnet College Park, MD 145 1800 ICM (FIX-East) Merit has started collecting routing table snapshots from the NSFNET Backbone Service and SNMP stats (in/out packets, in/out bytes), and will continue to do so throughout most of the day tomorrow. If there is a catastrophic failure tomorrow morning, Merit will advise the ANS NOC to roll back to the previous configuration (those installed Friday morning during the normal configuration window). If it is determined that problems are isolated to individual autonomous systems, Merit will enable the sessions with those individual autonomous systems. If there are individual routes from many sources which are unreachable, Merit will designate one emergency configuration time period at which all of the independent additions will be made. This time period will probably be late Friday or early Saturday. If you are experiencing problems tomorrow after 0900 EDT, please send mail to merit-ie(a)merit.edu, or trouble(a)ans.noc, or call 1-800-456-6300. Merit engineers will be on-call to address your problems. Thanks to all of you who have already ceased peering with AS 690, and to those of you who have worked so hard to meet the April 21, 1995 deadline. Hoping not to hear from you tomorrow. :-) --Elise

2 1

RE:
by jnolan＠dircon.co.uk 21 Apr '95

21 Apr '95

Alexander, For some reason your request to join the RIPE mailing list came through to me. Can I suggest you try again. Regards John Francis Nolan ------------------------------------- All is flux, nothing is stationary 04/19/95 19:08:46

2 1

(no subject)
by Alexander Albler 19 Apr '95

19 Apr '95

SUBSCRIBE alexander.albler(a)iic.wifi.at ---------------------------------------------------------- Alexander Albler WIFI Interactive Information Center Koerblergasse 111 8010 Graz Austria/Europe Tel.: 43 316 602706 Fax.: 43 316 602711 alexander.albler(a)iic.wifi.at ----------------------------------------------------------

1 0

Re: Final transition steps
by Sean Doran 18 Apr '95

18 Apr '95

Um, are these April 21 disconnections going to be permanent, or is this just a test of limited duration (six or seven hours, say)? If the turn-off is going to last a long time then the NSFNET International Connectivity Project will need MERIT to process and have installed, no later than this Wednesday, a NACR with changes to about 16000 prefixes. We can prepare the NACR this weekend. We will also need to know whether this is a full turn-off of the NSFNET backbone service next Friday as it will affect our immediate plans for turning up an ICM DS3 connection to MAE-EAST+, effectively moving the timing of that forward a few days. (To get the ICM DS3 up and running on time for the 21st (instead of before the 30th) we have some timing issues that are pretty critical, namely provisioning the DS3 and installing all the equipment. It is unclear that this is possible on the MFS side (never mind the paperwork process, which we probably will just have to ignore in the short run). What is clear though is that current connectivity to MAE-EAST is insufficient for making 21 April a happy day -- ICM is transiting SprintLink's (too full) DS3 to MAE-EAST, and using the FIX to reach the fednets and the networks which have not yet transitioned; the current DS3 can't support moving 10Mbps from the FIX, and don't even mention the ethernet that ICM still has today). I am not opposed to the idea, nor to the implementation of this push towards finding alternate connectivity. However, I'm pretty annoyed that we got very short notice of what appears to be an early shutdown of the NSFNET backbone service. This is especially irritating as a shutdown on the 21st will dramatically affect routing worldwide, and force a rewrite of a number of transition schedules which have been in place for quite some time. However, let's run with it. We'll know early in the week when Peter, Vadim and I have spent alot more time on moving ICM transition forward how bad things will be at 9am on the 21st as opposed to the evening of the 26th, and then again late at night on the 30th. Right now, I humbly request that MERIT wearing its RA hat quickly (i.e., this weekend, and certainly no later than Wednesday morning) locates an RS at FIX-EAST so that ICM can more rapidly bring up safe peering with the FIX-EAST connectees than we had initially planned (i.e., we need to have functional peering and transit set up this week instead of using this week to debug things with the fednets who are facing disconnectivity as of the 30th). This RS should be seeded from the ENSS145 configurations rather than any other source. Having something in place at FIX-EAST which does the same filtering that the AS 690 PRDB mechanism did has now been made much more urgent than it was yesterday, so that we can avoid rushing direct peerings, which traditionally has resulted in serious routing botches that the whole world notices. Sean. - -- Sean Doran <smd(a)icm1.icp.net>

3 2

Re: Final transition steps
by Elise Gerich 18 Apr '95

18 Apr '95

Push, The following peering sessions will be unaffected: PacBell NAP ----------- CRL AS 2041 Net99 AS 4388 Route server AS 2882 ANS AS 1321 AS 1688 ANS CIX AS 1957 Sprint NAP ---------- Sprintlink AS 1239 CERFnet AS 1740 Route server AS 2884 Test-RS AS 2886 networkMCI AS 3561 MAE-East -------- Netcomm AS 2551 Route server AS 2885 Interpath AS 3407 networkMCI AS 3561 Net99 AS 3830 B3net AS 4136 Alternet AS 701 Sprintlink AS 1239 CERN/Dante AS 1674 PIPEX AS 1849 Europe RS AS 1879 PSI AS 2149 AADS NAP -------- networkMCI AS 3561 AADS AS 3421 ANS AS 1323 AS 1688 FIX-West -------- NASA AS 297 AS 372 ESnet AS 293 AS 3429 DREN AS 668 DSI AS 2699 Milnet AS 568 network MCI AS 3561 NASA-test AS 1263 Sprintlink AS 1239 Anyone wishing to peer with ANS post-April 30 should contact ANS directly. --Elise >Pushpendra Mohta writes: > > > Sorry- Last nagging question. AS1740 has a AS690 peer at the NY NAP. > Since I dont see the NY NAP ENSS on this list, should I assume > that that peering wont be affected ? > > > > Elise Gerich writes: > > > > >Pushpendra Mohta writes: > > > > > > Elise > > > > > > Will this apply to the peers at the NAPs ? The New York NAP > > > in particular ? > > > > > > --pushpendra > > > > > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > > > Director, CERFnet http://www.cerf.net +1 800 876 2373 > > > > > > > To better clarify which Autonomous Systems will be effected by the > > April 21, 1995 action, here is a list of the NSFNET Backbone Service > > nodes and the associated Autonomous Systems that are proposed to be > > effected. Due to some information that we have received from one > > or two organizations, this list may be modified. > > > > --Elise > > > > City ENSS# Associated AS# > > -------------------------------------------------------------------------------- > > Ann Arbor, MI 131 237 MICHnet > > 1225 CICnet > > > > Argonne, IL 130 683 Argonne > > 1225 CICnet > > > > Boston, MA 134 560 NEARnet > > 701 Alternet > > > > Boulder, CO 141 58 Los Alamos > > 278 MexNet > > 297 NASA > > 2648 NIST > > > > Champaign, IL 129 38 UIUC > > 555 MSC > > 698 UIRnet > > 1224 NCSA > > 1225 CICnet > > > > College Park, MD > > (FIX-East) 145 293 ESnet > > 297 NASA > > 568 Milnet > > 668 DREN > > 699 DSI > > 1800 ICM > > > > Houston, TX 139 114 Sesquinet > > 297 NASA > > 3354 THEnet > > > > Ithaca, NY 133 174 PSI/NYSERnet > > 133 gated testing > > > > Lincoln, NE 140 93 MIDnet > > > > Palo Alto, CA 128 199 BARRnet > > 200 BARRnet > > > > Pittsburgh, PA 132 204 PSCnet > > 1206 PSCnet > > 3577 Prepnet > > > > Princeton, NJ 137 97 GES/Jvncnet > > 1250 Princeton > > > > Salt Lake City,UT 142 210 Westnet > > > > Seattle, WA 143 685 NorthWestNet > > 73 NorthWestNet > > > > San Diego, CA 135 195 SDSC > > 1740 CERFnet > > 1838 CERFnet > > 2150 CSUnet > > 22 NOSC > > > > NASA Ames, CA 144 200 BARRnet > > > > > > --pushpendra > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > Director, CERFnet http://www.cerf.net +1 800 876 2373 > >

1 0

Final transition steps
by Elise Gerich 15 Apr '95

15 Apr '95

We are approaching the last weeks of the NSFNET Backbone Service. Despite good intentions, only seven (7) organizations have completely severed their relationship with the NSFNET Backbone service. Those seven (7) are: Argonne National Laboratory CA*net Cornell Supercomputer Center DARPA Michnet NYSERnet SURAnet Many other organizations depend on a new service provider and they continue to maintain the NSFNET connectivity for backup purposes. Merit has encouraged organizations who maintain redundant connectivity to voluntarily discontinue connectivity to the NSFNET service in advance of April 30,1995. The reason prompting this request is that it is difficult to identify outstanding reachability issues as long as there are still dependencies on the NSFNET Backbone service. If an organization can confirm reachability to all destinations that are currently reachable, the chances for an uneventful changing of the guard on April 30 increase. To this aim, Merit is encouraging all organizations which will lose direct access to AS 690 on April 30, 1995 to decommission their peering sessions with AS 690 before April 21, 1995. On April 21, 1995 at 09:00 EDT, Merit will terminate peering sessions with all organizations still attached to the NSFNET Backbone service. The goal of this action is to identify where there are pockets of unreachable destinations. At the NSFNET Executive Committee meeting which took place on April 12, 1995, the committee expressed concern over the large amount of traffic still traversing the NSFNET service. Based on this concern, the committee requested that Merit take the actions described in this message. If an organization identifies a reachability problem between April 21 and April 28, it should send a message to merit-ie(a)merit.edu. We will work with the organization to resolve the problem and will reestablish temporary access to the NSFNET service as necessary. On April 28, 1995, all sessions with the NSFNET service will be permanently terminated and ANS will terminate operation of the NSFNET Backbone service on April 30, 1995. The following locations where access to the NSFNET service is provided will be impacted by this discontinuation of service on April 21, 1995: Ann Arbor, MI Argonne, IL Boston, MA Boulder, CO Champaign, IL College Park, MD (FIX-East) Houston, TX Ithaca, NY Lincoln, NE Palo Alto, CA Pittsburgh, PA Princeton, NJ Salt Lake City, UT Seattle, WA San Diego, CA Please send any questions regarding this plan to merit-ie(a)merit.edu. Thank you. --Elise Gerich Manager, Internet Engineers Merit Network Inc.

1 0