Mailing List Archive

Congratulations!
--Elise

>Steve Heimlich writes:
>
> Folks,
>
> As previously mentioned, ANS is moving to a new configuration system
> which will eliminate the need for registering AS690 advisories with
> RIPE-181 route objects. Our initial deployment described below
> has gone well, and as a result we will freeze our aut-num (currently
> still machine generated based on advisories) on Friday, 11/17, at
> midnight ET (Saturday, 11/18, 5am GMT). Tuesday morning's AS690
> config run will use the frozen aut-num.
>
> 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.
>
> Refinement of AS690 import policies will begin on a per AS basis
> next week, starting with large origin ASes. The human readable
> version of the 18,000 line AS690 aut-num is currently available
> at:
>
> ftp://ftp.ans.net/pub/info/routing-stats/aut-num-as-690
>
> Steve
>
> --------
> To: nanog@merit.edu
> Subject: AS690 policy configuration changes
> Date: Mon, 06 Nov 1995 18:43:22 -0500
> From: Steve Heimlich <heimlich@kingbee.ans.net>
>
> All,
>
> Starting with Friday [11/10] morning's config run, AS690 will pick
> up any route listed in various routing registries, including both
> those routes with advisories and those routes without advisories.
>
> ANS customers will not be affected by this change.
>
> Routes without advisories will be examined for origin AS and will
> inherit the most popular policy currently used for that AS. For
> example, if a route for 147.225/16 (origin AS1660) were listed
> without an advisory, we would configure ourselves to listen for
> 147.225/16 in the same way that we listen to most other AS1660
> routes (only from AS 1324 in this case).
>
> If a route is registered in an AS for which we don't have existing
> policy, it will not be routed. In the example above, if 147.225/16
> were registered without an aggregate, and it were the only route
> registered with origin 1660, then we will not route it. We have
> a tool which flags such new ASes, and policy toward them will be
> created regularly. The rate of growth in number of ASes is not
> high, particularly relative to the rate of growth in number of
> routes.
>
> For now, we will continue to build our policy dynamically from the
> advisory attributes. Assuming that this hybrid deployment goes
> well, we intend to freeze our policy and convert to a system which
> ignores advisories altogether. With this system, the mechanics of
> shifting policy will be quite easy (essentially involving only
> ANS). I expect to announce that freeze and shift in the next week
> or so. At that point, those folks who want to strip AS690 advisories
> from any database may do so without a problem; as mentioned above,
> any advisories registered after that time will be ignored.
>
> 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.

in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object
and list themselves as the origin, and put AS#1 in the advisory. in the
new scenario, will ANS now only allow routes coming via the ASN in the
ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field
to AS#1 so ANS knows where to look for for the routes?

- elliot alby/sprintlink implementation

> 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.

in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object
and list themselves as the origin, and put AS#1 in the advisory. in the
new scenario, will ANS now only allow routes coming via the ASN in the
ORIGIN field? i.e. will AS#2 have to change the ASN in the origin field
to AS#1 so ANS knows where to look for for the routes?

- elliot alby/sprintlink implementation

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.
>
> in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object
> and list themselves as the origin, and put AS#1 in the advisory. in the
> new scenario, will ANS now only allow routes coming via the ASN in the
> ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field
> to AS#1 so ANS knows where to look for for the routes?
>
> - elliot alby/sprintlink implementation
>

What happens if policy changes for those AS'es?

i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*)

How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies?

_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.
> >
> > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object
> > and list themselves as the origin, and put AS#1 in the advisory. in the
> > new scenario, will ANS now only allow routes coming via the ASN in the
> > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field
> > to AS#1 so ANS knows where to look for for the routes?
> >
> > - elliot alby/sprintlink implementation
> >

Greetings-

Your request has been received by our IP addressing staff,
and will be attended to as soon as possible. The staff member in
charge of your request will notify you when it is completed.

Due to the volume of mail processed, it may take up to one
business week to complete your request. Requests for new IP addresses
may take longer to process. If you have a question about your request,
or need to refer to it later, your NACR ticket number is SER1114-160833.
Please include this id in any mail pertaining to this request.

Additionally, if you are looking for any of our forms, please
check our ftp server at ftp://ftp.ser.bbnplanet.net/pub/forms


-NACR

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.

Steve

>
> What happens if policy changes for those AS'es?
>
> i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to ro
> ute through AS701. (*grin*)
>
> How is new policy to be determined, either for new ASes, or for existing ones
> that drastically change their routing policies?
>
> _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.
> > >
> > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object
> > > and list themselves as the origin, and put AS#1 in the advisory. in the
> > > new scenario, will ANS now only allow routes coming via the ASN in the
> > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field
> > > to AS#1 so ANS knows where to look for for the routes?
> > >
> > > - elliot alby/sprintlink implementation
> > >
>
>
>

Greetings-

Your request has been received by our IP addressing staff,
and will be attended to as soon as possible. The staff member in
charge of your request will notify you when it is completed.

Due to the volume of mail processed, it may take up to one
business week to complete your request. Requests for new IP addresses
may take longer to process. If you have a question about your request,
or need to refer to it later, your NACR ticket number is SER1114-162451.
Please include this id in any mail pertaining to this request.

Additionally, if you are looking for any of our forms, please
check our ftp server at ftp://ftp.ser.bbnplanet.net/pub/forms


-NACR

> 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.

Oh, and sorry about that spam.
*cringe*

_k

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

In message <199511131647.LAA14006@home.merit.edu>, Elise Gerich writes:
> Congratulations!
> --Elise

Since the series message of nearly a month ago did not reach both of
these mailing lists, I'd like to say thank you to Merit for their role
in making this possible. Merit applied a few remaining changes to
radbserver, froze a copy of all of the databases and set up an
radbserver on an alternate port serving this frozen database. This
made it possible for us eliminate any synchronization problem
(fetching the databases at different times) and compare config files
generated using Merit's Solaris servers and our AIX client end and our
own BSDI servers and client end. One remaining small bug in our code
was found and fixed as a result of this, saving outage for a small
number of prefixes. We were able to account for every difference in
what has now grown to 270,000 lines of configs (almost all of the
differences were addition of the routes with no advisories).

Curtis