sgoldste at nsf.gov
Mon Feb 6 16:49:46 UTC 1995
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.
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
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 at sprint.net> and/or Vadim Antonov
<avg at 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.
Date: Fri, 13 Jan 1995 13:16:12 -0500
From: Elise Gerich <epg at merit.edu>
To: nwg at home.merit.edu
Subject: Change in NACR procedures
Cc: epg at 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 at merit.edu as soon as possible.
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 at 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 at merit.edu
and the NACR is received from epg at pepper.merit.edu, it will
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 at 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.
As of January 20, 1995, Merit will begin to implement this change.
If mail to nsfnet-admin at 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
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.
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 at 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 at 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.
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)
sgoldste at NSF.GOV
More information about the NANOG