PRDB retirement (and note about AS690 advisories)


Thanks to Dale for the initial update. Let me add a further note
on our transition of AS690 from NSFnet routing policy toward ANS
routing policy...

Shortly beyond retirement of the PRDB, ANS will halt our use of
AS690 advisories. We hope to do this soon after retiring the
PRDB, using a tool which converts existing announcements into policy
expressable using "pure" RIPE-181; this resulting aut-num object
will work with various standard RIPE/PRIDE tools.

After that, we'll be culling our very large aut-num object into
something smaller which is uses AS-based policy as much as possible,
with a minimum of prefix-based exceptions. New registered prefixes
will assume the current majority policy toward the home AS in which
they're registered. The size of the aut-num object right now comes
from handling the large number of exceptions for prefixes originating
within a given AS (which we're using so that we disturb actual
routing as little as possible initially).

The configuration of metric:as lists has been a challenge to manage
to say the least, particularly through the transition. As they
are obviously burdensome for ANS as well, we have a mutual interest
in witnessing their retirement, and we're working to do this as
quickly as possible.

In addition, info in the RADB which has as its source "PRDB" can
be ignored on a per-provider basis, so that eventually the PRDB-derived
info can go away entirely. So, if provider X tells us to prefer
source:X over source:PRDB, we can work out migration details so
the old PRDB info can be knocked out in one action, replaced by
the preferrable RIPE-181 source.


--------------- Dale's original follows ----------------

           What Networks Need to Do When the PRDB Is Retired

On Monday, May 8, the Policy Routing Database (PRDB) will be turned off.
The PRDB has been used to configure the NSFNET Backbone Service and
ANSNET (AS690) since 1989. After May 8, configurations for the ANSNET
backbone will be generated from the Routing Arbiter Database (RADB).

The PRDB and the RADB have been running with parallel data for over a
year. As of May 8, the last data from the PRDB will be transferred to
the RADB, and the PRDB will be permanently retired.


Starting 09:00 EST May 8, NACRs will no longer be accepted for AS690
configurations; the way to submit additions or changes of route
announcements for AS690 will be to submit Route objects by e-mail to

If you submit a NACR after 09:00 May 8, you will receive a reply that
gives you a translation of that NACR into a Route object and explains
how to mail that Route object to for immediate inclusion
in the RADB. For an overview of the RADB and more information about
creating and submitting Route objects, see: (select Routing Arbiter from the Projects menu)


Under the old NACR/PRDB system, each AS maintained a list of "valid
requestors" who could make routing changes for that AS. Under the new
Route object/RADB system, each network has an Origin AS ("Home AS"); the
individuals who can make routing changes for that AS's networks are
listed in the Maintainer object for that AS. Initial versions of
Maintainer objects were created from the PRDB "valid requestor"
information on February 1, and many more Maintainer objects have been
added to the RADB since then. Thus it is very likely that your
authorization in the RADB has already been established. If you have
successfully submitted a NACR since February 1, then you are already
authorized to submit Route objects for that AS.

Note, however, that if another organization has been submitting NACRs
for you, that organization may no longer be authorized to do this under
the RADB unless you specifically include e-mail addresses for that
organization in your Maintainer object. Here is the breakdown of
authorized submitters:

    Date Who Can Make Routing Changes
    ------ ------------------------------
    Before Feb. 1 Any valid requester of any AS in the
                            network's announcements ("aslist"),
                            including the Primary AS
    Feb. 1 - May 8 Persons specified by the Maintainer objects
                            of *either* the network's Primary AS or
                            its Home AS
    After May 8 *Only* persons specified by the Maintainer
                            object of the network's Home AS

The e-mail addresses for people authorized to make changes for your
network must be listed on separate MAIL-FROM lines in your Maintainer
object. (A more elaborate system can be used after May 8.) To verify
that your Maintainer object contains the correct information, enter a
command such as the following:

    whois -h MAINT-AS690

For more information on checking, submitting or updating Maintainer
objects, see: (select Routing Arbiter from the Projects menu)

If you have further questions about registering in the RADB, send e-mail

              --Dale Johnson

I am not sure that nanog is the right place for this, since it affects
folk outside North America.

New registered prefixes will assume the current majority policy toward
the home AS in which they're registered.

What if the current majority policy for that AS is that most nets did not
have NSFNet routing, and are announced to ANS via the CIX? It might make
more sense to exclude non-NSFNet routes when determining the majority

Many folk have routes that did not have NSFNet routing and that were
announced to ANS via the CIX (with aslist 1:1957). What should be done
with those? Should we send in new NACRs to change the aslist?

Some non-NSFnet aggregates contain more-specific routes that do (or
rather, did) have NSFNet routing. How soon can we withdraw the
more-specifics? I fear that bad things will happen if we withdraw the
more-specifics without first changing the aslist on the aggregate.

How will ANS's new routing policy affect the peering between ANS and the
CIX? Is it still prohibited for ANS to hear the same route both through
the CIX and through a non-CIX connection? Should CIX members send in
new NACRs that include as1957 in aslists where it was not previously
included, or will ANS figure out something suitable without needing a
lot of new NACRs?

--apb (Alan Barrett)