[lots of trimming]
* > 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.
*
I think the issue is where you build the config from ultimately,
the as-out of aut-num or some peer to as-macro mapping. We've had to do
this in some cases for lack of update to aut-num. FWIW, MCIs RR has
19,269 routes, 43 AS-MACROS and 172 aut-nums.
We could do something like stick the macro in our as-in and expand
policy from there, for starters.
* > 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.
*
No sure how this is acheived ?. For something totally new as Kobi
mentions how can you assume anything about it or am I missing
something ?
We use the magical escape hatch, which means we look at where the
route is coming from if it weren't filtered (and there are plenty
of examples of that today) and make a great guess. In an ideal
world (one in which everything is filtered 
), this wouldn't
work, of course, and we'd have to do something more intelligent
(like provide some mechanism for "advising" folks where to find
things ).
<ramble begins>
Some sort of scalable, easily maintainable advisory mechanism would
be cool to have, but I haven't really thought about it too much.
I'm certain that a tool could be written to do a search over the
graph of ASes defined in all the registries, but we'd need to make
sure that the registered information accurately reflected global
AS topology. Using this tool once a day (or however often), you
could get a view of the paths to any AS from your own point of view
(e.g., from 3561 or 690 to anywhere). Almost like an administrative
version of IDPR I suppose. The backend of that thing could munge
your aut-num (or provide a nice list of suggestions).
<ramble ends>
* > 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.
*
Okay so that's how it works. You dont accept it ;-). The provider has
to register his policy is all. Sort of seems fine but you might find
this an uphill curve at the start.
We've seen steeper hills.
Steve