Comments inside.
In theory, this would be covered by moving AS279 from the AS macro for MCI to the AS macro for UUnet.
So, this also goes for new ASes?
AS macros, when used, will handle new ASes just fine.
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.
It's an option which potentially scales nicely. We'd coordinate this on a per peer basis rather than on nanog though. :-)
How many AS macros are there now, in the radb, ans, and ripe RR's?
I haven't counted recently.
[i left out mci because i know how many there are, especially since it is a s plit db ;-]
Are the AS-macros only referenced recursively after parsing the aut-num, or are they to be applied to policy independantly?
I'm not parsing this one.
How is policy to be determined for AS5757, should someone start announcing it tommorrow?
Two possible ways: 1) in the future setup with AS macros, it would be treated consistently wrt. the macro in which it sits, assuming that we already have policy for that macro. 2) in the current setup, one of our tools picks this new AS up and we write policy in our aut-num for it. If it's not obvious, we coordinate with appropriate peers.
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?
Not likely today. Future (i.e., with macros), sure. We have a few AS macros ourselves. For example, AS-ANS is our top level. I'll admit that if these are to be used correctly, they have to be maintained (that's a pretty easy task really, unless one is trying to clean up lots of other gorp first, which is the current case). Steve