mailing list archives
Re: PRDB retirement (and note about AS690 advisories)
From: Alan Barrett <barrett () daisy ee und ac za>
Date: Wed, 3 May 1995 22:41:11 +0200 (GMT+0200)
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
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)