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.
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
Discussion may be better placed on rps list. Adding to cc: line. Steve Heimlich <heimlich@ans.net> writes: * 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. :-) * Well this is interesting and something we've also found to be the way we've had to go. i.e. encouraging the use of AS-MACROs to define set of policy for a peer becuase in general it ends up covering things nicely. When we originally did ripe-181 specfication back in stone age now this was not really the intent and was meant as a vehicle for keeping the as-in specification size down and readable (laugh!) but seems to work nicely. * > 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. * 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. * > 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 ? * > 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 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). Ditto - check out AS-MCITRANSIT (we only do a little bit of transit;-)). * Steve * --Tony.
[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
Steve Heimlich (heimlich@ans.net) on November 14:
<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>
Steve, Currently under development here at ISI is a tool that we call a what-if database. It will enable one to change policies temporarily (i.e. without actually registering in any database) and do analysis. For example, you can change your as-in policies to ANY and use prpath to find paths or prconn (currently being developed) to find all the reachable destinations. The tools, when interacting with the what-if database, may give you the delta of the changes. Hence, the result of prconn may be the new address/prefixes that are now reachable and were not before and vice versa. Of course, for this tool to be useful, radb needs to be cleaned up of bogus aut-num objects, and decent aut-num objects need to be maintained by all (well most:-). Do you think something like this covers what you want? Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz
Yep, sounds useful (for starters). How about a tool to clean up the RADB? :-) Steve
Steve Heimlich (heimlich@ans.net) on November 14:
<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>
Steve,
Currently under development here at ISI is a tool that we call a what-if database. It will enable one to change policies temporarily (i.e. without actually registering in any database) and do analysis. For example, you can change your as-in policies
to ANY and use prpath to find paths or prconn (currently being
developed) to find all the reachable destinations. The tools, when interacting with the what-if database, may give you the delta of the changes. Hence, the result of prconn may be the new address/prefixes that are now reachable and were not before and vice versa.
Of course, for this tool to be useful, radb needs to be cleaned up of bogus aut-num objects, and decent aut-num objects need to be maintained by all (well most:-).
Do you think something like this covers what you want?
Cengiz
-- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz
participants (4)
-
Cengiz Alaettinoglu -
ser-rr＠ser.bbnplanet.net -
Steve Heimlich -
Tony Bates