AS690 advisory update

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. :slight_smile:

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:

descr: A route that can't get everywhere
origin: AS5757
mnt-by: MAINT-AS5757
changed: 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).