This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Proposal on applying advisory attribute to "aut-num" object
- Previous message (by thread): Proposal on applying advisory attribute to "aut-num" object
- Next message (by thread): Proposal on applying advisory attribute to "aut-num" object
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Curtis Villamizar
curtis at ans.net
Mon Oct 23 19:03:54 CET 1995
In message <9510211419.AA25411 at banknet.banknet.net>, Janos Zsako writes: > > From owner-db-wg at ripe.net Fri Oct 20 21:22:16 1995 > > Christian, > > > The famous "advisory" attribute which seems to be still needed by ANS > to > > get their routing done is especially cumbersome because it has to be > > applied to and maintained for every single "route" object. If the > > "advisory" attribute could be added to the "aut-num" object, entering > an > > "advisory" there could cover all routes originated by this AS. Of > > course the ANS people will have to slightly modify their software. > > As far as I see David Kessens has already made the necessary changes in the D > B > software. :) > > zsako/banknet $ whois -h whois.ripe.net "-t aut-num" > aut-num: [mandatory] [single] > as-name: [optional] [single] > descr: [mandatory] [multiple] > as-in: [optional] [multiple] > as-out: [optional] [multiple] > advisory: [optional] [single] <<<<<<---------- > interas-in: [optional] [multiple] > interas-out: [optional] [multiple] > as-exclude: [optional] [multiple] > default: [optional] [multiple] > guardian: [optional] [single] > admin-c: [mandatory] [multiple] > tech-c: [mandatory] [multiple] > remarks: [optional] [multiple] > notify: [optional] [multiple] > mnt-by: [mandatory] [multiple] > changed: [mandatory] [multiple] > source: [mandatory] [single] Please don't expend any effort in this direction. We have been hesitant to make any announcements since in the past our target dates have come an gone with no elimination of the advisories. I've just done some checking, and we are now ready to commit to deployment within two week. For over a month we have been generating configurations on our development machine in which there is a perfect match between the advisory based configs and those generated using policy expressed in the autnum. We have been unable to resolve all of the differences between the configs we use in production and the development configs. The primary problem has been that there are bugs in the version of radbserver that Merit is running. Though we have fixed our copy of radbserver and provided patches, Merit has not yet applied them. There are over a thousand differences, which is two high a number to be resolved manually. We believe the remaining differences are solely due to the unfixed radbserver bugs and syncronization between config databases used by the two machines. We have decided to waive the final consitency check and move forward anyway. The reamining time before deployment is to insure that the NOC is sufficiently familiar with the changes (we are making changes to our own config process in the process of doing this), are satisfied with the robustness of the automated portions of the process and the notification provided as the steps procede, and with troubleshooting procedures now that tools that rely on the advisories will no longer work. If you do start to put advisories in the autnum, none of the tools used to generate configs will use this field. This is equivalent to not providing any advisory at all since it will have the same effect. If we were to go in the direction of supporting this, the time it will take to correct this in radbserver, peval, and elsewhere is likely to be far longer than the time remaining to get rid of advisories altogether. It will also require changes to the code that generates the AS690 autnum and further delay the elimination of AS690 advisories. We will be cleaning up the generated AS690 autnum after we stop the regular automatic generation of the autnum and ignore the advisories. Any route that does not have an advisory at that point will get the same routing as the majoprity of routes with the same origin AS at the time when we freeze the autnum. Clean up to follow will involve reviewing policies for specific origin AS and trying to make them routing consistent across entire origin AS where possible. Curtis
- Previous message (by thread): Proposal on applying advisory attribute to "aut-num" object
- Next message (by thread): Proposal on applying advisory attribute to "aut-num" object
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]