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