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
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
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
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
participants (4)
-
Curtis Villamizar -
Elise Gerich -
Elliot Alby -
Steve Heimlich