In theory, this would be covered by moving AS279 from the AS macro for MCI to the AS macro for UUnet.
In current practice, because AS macros are not widely in use (and aren't in our machine generated aut-num right now), this will have to be coordinated among providers (like you send us a note saying your entire AS has moved).
The idea is that this doesn't happen all that often. If it does, the AS macro is a decent way of handling it.
So, this also goes for new ASes? And you're saying that everyone that peers with you should start using AS macros in addition to aut-nums to both add new ASes and re-arrange policy for old ones. How many AS macros are there now, in the radb, ans, and ripe RR's? [i left out mci because i know how many there are, especially since it is a split db ;-] Are the AS-macros only referenced recursively after parsing the aut-num, or are they to be applied to policy independantly? How is policy to be determined for AS5757, should someone start announcing it tommorrow? In other words, say this appeared in the RADB tonight: route: 206.197.210.0/24 descr: A route that can't get everywhere origin: AS5757 mnt-by: MAINT-AS5757 changed: kobi@kobi.edu 951114 source: RADB And someone, pick a provider, started announcing this to you tommorrow. Say Sprint. Would it be accepted? And why? _k
Elliot,
Ignore the advisory. If AS2 is the origin, we will route traffic for that particular prefix/masklen using the most common policy already in place for routes in AS2.
If the common policy is for us to send traffic destined for AS2 via our peer AS1, we will continue to do so for the new prefix/masklen.
Steve
After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today.