At 7:36 PM 2/06/95, Vasenin Valery A wrote:

Dear Steven!

I'm deeply grateful to you for the timely solution about the announcement MSUNet in NSF.

Sincerely yours Valery Vasenin.

Dear Valery, Actually I had not done ANYTHING...yet. I read your first message earlier this morning, and had not yet had the opportunity to look into the exact nature of the problem, and then I get this new message from you. So, please let me try to explain a few things that might shed light on the problems of MSU's inablilty to communicate with portions of the NSFNET community from time to time. Two things are happening that are probably related to the problems you have been experiencing: 1. The NSFNET is being decomissioned (abandoned, going away), and it is being replaced with several interconnected national Internet service providers: MCInet, SprintLink, and ANSnet. The transition is taking place now and will last fur a few months, and things are not always stable during the transition. Route that work one hour may be replaced with routs that do not always work in the next hour, and these have to be identified and corrected. 2. The routers on the East Coast of the United States, mainly around Washington, D.C., are "glowing red hot" with traffic overloads. Some new code has been written to improve their performance, and network experts try to install the new code and observe its performance at low traffic times here (around our midnignt), which correspond to periods of high activity in Russia with the 8-hour time difference. One by-product of all the attempts to upgrade the code is "route flapping" instability,in which the connectivity and routing information contained in the routing tables cannot keep up with the changing physical realities of the network itself: there is just too much work for the routers to do, and they cannot keep up with both packet switching and routing table updating. So, if your problems corrected themselves without my intervention at all, my guess is that one or both of the above mechanisms must be the culprits. If you continue to experience intermittent problems, please have your technical people write to Sean Doran <smd@sprint.net> and/or Vadim Antonov <avg@titan.sprintlink.net> at Sprint with the precise description of the problems as you see them. There is no policy reason of which I am aware that would cause the problems that you have experienced. We have been routing traffic from Russia for at least a year, and I recall having seen that a new MSU network has just been added to the data base. MAYBE what you have observed is that the addition of the newly registered MSU network entry has just taken effect. Below, i will copy a notice about the [proposed] new procedures to replace the current NSFNT procedures for registering routing information. Best wishes, Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Fri, 13 Jan 1995 13:16:12 -0500 From: Elise Gerich <epg@merit.edu> To: nwg@home.merit.edu Subject: Change in NACR procedures Cc: epg@home.merit.edu In preparation for the retirement of the PRDB and the move to the Routing Arbiter (RA) architecture, Merit proposes to change our NACR-handling procedures to more closely mimic the registration procedures of the Internet Routing Registries. We propose to implement these changes on January 20, 1995. Please send any comments regarding the changes to merit-ie@merit.edu as soon as possible. Procedural changes: 1. NACRs for a given net will only be accepted from designated email addresses from the net's home AS or from the AS which is currently listed as the primary path according to the PRDB. To verify what the designated email addresses are for your Autonomous System number, use the whois client: whois -h prdb.merit.edu contact <as number> To update the designated email addresses for an Autonomous System, send email to DB-admin@ra.net. Please register the exact email address which will be used to add or change information in the PRDB. For example, if the designated email address is epg@merit.edu and the NACR is received from epg@pepper.merit.edu, it will be bounced. In general we anticipate that this change should pose little or no problem. In the event that a net changes providers, one of the following two procedures will have to be followed. Either (a) the administration of the net's home AS sends a NACR specifying the new provider as primary (and possibly deleting the old), or (b) the administration of the old provider sends the NACR. If the new provider wants to submit the NACR, they will need to send it to the administration of the home AS for forwarding to Merit. Very few administrators of home ASs which are behind ASs that peer directly with AS 690 have designated individuals and their associated email addresses as authorized to update the PRDB. For more information in establishing an aslist with Merit, please send a message to DB-admin@merit.edu. 2. ACKs/NACKs for NACRs will no longer be required, and in fact, will be ignored if received. 3. Copies of accepted NACRs will be sent to all associated ASs. This includes notification of changes to nets already in the PRDB. Typically, we would expect that all the ASs which are associated with a net would be aware of any change in routing preferences. However, this notification procedure will alert ASs that a change has taken place even if they had not previously been informed about the change. NACR Processing As of January 20, 1995, Merit will begin to implement this change. If mail to nsfnet-admin@merit.edu contains a NACR originated from an authorized account as described in procedural change (1), it will be processed. If it didn't, the mail will be bounced. If for some reason you want your NACR to be read even if it would otherwise be deemed unacceptable, include a non-null comment: field in the NACR. Summary: This is the first step in providing a transition to the RA architecture. We have been experiencing an increase in the number of NACRs which are being submitted to the NSFNET Backbone Service, many of which pertain to the movement of networks from one provider to another. For the month of December, nsfnet-admin@merit.edu received more than 4200 messages. More than 1200 changes were made to the PRDB on January 13, 1995. These new procedures will help to make the registration process more manageable. For those organizations which are in the process of changing to another provider (autonomous system), the organization can improve its chances of having changes to the PRDB made in a timely fashion and to protect itself against loss of reachability by: a. sending NACRs in advance of your cutover (at least one week) b. adding the new provider as secondary (tertiary, etc) c. having the new provider start announcing the route d. testing the route by having previous provider stop announcing the route e. sending a NACR deleting the previous provider Please check that you have designated correct email addresses for your Autonomous System prior to January 20,1995. Mail to nsfnet-admin@merit.edu which is a valid template and originates from an undesignated email address will be bounced back to the originator of the message starting on January 20, 1995. Thank you in advance for your cooperation. --Elise ================================================================ Steven N. Goldstein Program Director, Interagency & International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste@NSF.GOV ================================================================