|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: AS690 advisory update
Discussion may be better placed on rps list. Adding to cc: line. Steve Heimlich <[email protected]> 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: [email protected]i.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.
|