Thank you

Steve Goldstein sgoldste at
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.

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 at> and/or Vadim Antonov
<avg at>  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,



Date: Fri, 13 Jan 1995 13:16:12 -0500
From: Elise Gerich <epg at>
To: nwg at
Subject: Change in NACR procedures
Cc: epg at

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 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 contact <as number>

To update the designated email addresses for an Autonomous
System, send email to DB-admin at 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
and the NACR is received from epg at, 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 at

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 at 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 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 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)
  FAX: +1-703-306-0621
  sgoldste at NSF.GOV

More information about the NANOG mailing list