AS690 advisory update

Wed Nov 15 03:18:37 UTC 1995

Discussion may be better placed on rps list. Adding to cc: line.

 Steve Heimlich <heimlich at 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 at 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.