PRDB retirement (and note about AS690 advisories)
Folks, 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. Steve --------------- 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. FROM NACRS TO ROUTE OBJECTS 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 auto-dbm@ra.net. 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 auto-dbm@ra.net for immediate inclusion in the RADB. For an overview of the RADB and more information about creating and submitting Route objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/OVERVIEW ftp://ftp.ra.net/routing.arbiter/radb/doc/how_to_register WILL YOU BE AUTHORIZED TO UPDATE THE RADB AFTER MAY 8? 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 whois.ra.net MAINT-AS690 For more information on checking, submitting or updating Maintainer objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/doc/updating_maintainers If you have further questions about registering in the RADB, send e-mail to DB-admin@ra.net. --Dale Johnson Merit/RA
I am not sure that nanog is the right place for this, since it affects folk outside North America. On Tue, 2 May 1995, Steve Heimlich wrote:
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 policy. 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)
Alan,
I am not sure that nanog is the right place for this, since it affects folk outside North America.
True, but I couldn't think of a better list.
On Tue, 2 May 1995, Steve Heimlich wrote:
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 policy.
This will take some time to clean up. See below...
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?
Well, the best thing I can think of is 1) we get rid of metric:as lists and 2) we modify our aut-num object on a per-AS basis to clean out exceptions like these routed only via the CIX, so that we route to them via major interchange points (MAE-East, Sprint NAP, MAE-West, Pac Bell NAP, ...). We probably don't want to do this until we axe the metric:as lists (so that we just do it once, on an AS-basis).
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.
In theory, immediately, though I agree that we should clean up/remove the advisories first as the more conservative approach while getting routing right for the aggregates. I'd hate to change all of those since I know they're going away Real Soon.
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?
We'll figure out something suitable and try to avoid metric:aslist shifts -- not overnight, but as part of this whole process of rationalizing policy. As I mentioned above, the most conservative approach will be to knock off ASes for which we have partial routing through the CIX one at a time. Steve
Steve,
Well, the best thing I can think of is 1) we get rid of metric:as lists and 2) we modify our aut-num object on a per-AS basis to clean out exceptions like these routed only via the CIX, so that we route to them via major interchange points (MAE-East, Sprint NAP, MAE-West, Pac Bell NAP, ...). We probably don't want to do this until we axe the metric:as lists (so that we just do it once, on an AS-basis).
OK. So my understanding then is that existing PRDB objects can be left alone, that new NACRS until 8 May still have to include "aslist:" fields, and that ANS wants new RR objects after 8 May to include "advisory: AS690" fields, but that ANS will soon stop wanting the advisory list.
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.
In theory, immediately,
If I withdraw the more-specifics immediately, then ANS will route them via the CIX instead of via better paths. However, if I were to imediately send in a NACR with a better aslist for the aggregate, then I would be able to withdraw the more-specifics without losing anything. Can I do that without having to promise to obey anybody's idea of a network AUP? I seem to have a three-way choice between doing nothing until ANS sorts out its configuration to no longer need aslists (in which case global routing tables are burdened by my more-specific routes for a while longer than they have already been burdened), withdrawing my more-specifics immediately (in which case they get worse routing from ANS than they had been getting), or sending in NACRs to change things (which involves extra work for a lot of people). I expect that my situation is not unique. I also want to echo Sean Doran's question of what text to put at the top of any NACR submitted before 8 May. It's not just the text at the top that presents a problem; even the "%begin nsfnet nacr v7.1" or "%begin ansnet nacr v2.0" no longer seems particularly apppropriate, and what do we put in the "aup:" line? --apb (Alan Barrett)
participants (2)
-
Alan Barrett -
Steve Heimlich