PRDB retirement (and note about AS690 advisories)

Alan Barrett barrett at
Wed May 3 20:41:11 UTC 1995


> 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)

More information about the NANOG mailing list