North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: AS690 advisory update

  • From: ser-rr
  • Date: Tue Nov 14 19:22:20 1995

> 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: [email protected] 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.