Re: Proposal on applying advisory attribute to "aut-num" object
From owner-db-wg@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 DB 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]
Comments welcome !
I would like to make some comments on the above. First of all, with respect to the `[single]' qualifier. If we indeed allow only one such advisory attribute for the AS (aut-num), then the AS can express its advisory recommendations to only one other AS for ALL of it routes. I know that this is somewhat theoretical, since only ANS use the advisory... Nevertheless ripe-130 says it could be used by any other organisation, although *everybody* is discouraged from using it at all. An other approach to this problem would not need any change in the DB schema. We have the `remarks' attribute which can be used for any additional information related to the AS. I think it could also contain something like: "advisory: AS690 1:1800 2:1133 3:1239" which means, the aut-num would have the following remarks attribute: remarks: advisory: AS690 1:1800 2:1133 3:1239 In this case any AS could add as many remarks as needed for the advisories... This is true for the `route' object as well. I know it is not a good practice to use the attributes for other purpose than they are designed for, but in this case I feel the advisory is not more than a remark (actually an important one if you want to have NSFnet connectivity...). Two other arguments are in favour of this second solution: first is that RIPE descourages people from using the advisory, second is that ANS should be ready with the new software soon, and then nobody would (or at least should) use the advisory any more. As you said, ANS have to make some (probably minor) changes in their software in order to get the advisory from the aut-num for all the routes originating in the AS corresponding to the aut-num. I do not think these changes are significantly less in the case there is an `advisory' attribute in the aut-num object, than in the case they have to parse the `remarks' attributes of the aut-num. Further comments welcome! Best regards, Janos Janos Zsako zsako@banknet.net BankNet Tel: +36 1 160 16 42 Fax: +36 1 160 14 06
Dear Janos,
Janos Zsako writes :
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 DB software. :)
True, I believe that we finally decided to put an action on the RIPE NCC to do just add it. I did the software change but the documentation is not ready so I didn't announce it yet. Note that it doesn't mean that ANS actually uses this attribute ...
First of all, with respect to the `[single]' qualifier. If we indeed allow only one such advisory attribute for the AS (aut-num), then the AS can express its
That should be [multiple], I just changed it. Kind regards, David Kessens RIPE NCC ---
First of all, with respect to the `[single]' qualifier. If we indeed allow only one such advisory attribute for the AS (aut-num), then the AS can express its advisory recommendations to only one other AS for ALL of it routes. I know that this is somewhat theoretical, since only ANS use the advisory... Nevertheless ripe-130 says it could be used by any other organisation, although *everybody* is discouraged from using it at all.
An other approach to this problem would not need any change in the DB schema. We have the `remarks' attribute which can be used for any additional information related to the AS. I think it could also contain something like: "advisory: AS690 1:1800 2:1133 3:1239" which means, the aut-num would have the following remarks attribute: remarks: advisory: AS690 1:1800 2:1133 3:1239 In this case any AS could add as many remarks as needed for the advisories...
This is true for the `route' object as well.
I know it is not a good practice to use the attributes for other purpose than they are designed for, but in this case I feel the advisory is not more than a remark (actually an important one if you want to have NSFnet connectivity...). Two other arguments are in favour of this second solution: first is that RIPE descourages people from using the advisory, second is that ANS should be ready with the new software soon, and then nobody would (or at least should) use the advisory any more.
As you said, ANS have to make some (probably minor) changes in their software in order to get the advisory from the aut-num for all the routes originating in the AS corresponding to the aut-num. I do not think these changes are significantly less in the case there is an `advisory' attribute in the aut-num object, than in the case they have to parse the `remarks' attributes of the aut-num.
Further comments welcome!
Best regards, Janos
Janos Zsako zsako@banknet.net BankNet Tel: +36 1 160 16 42 Fax: +36 1 160 14 06
An argument againts this proposal is that the need for advisory in the auth-num object is small when using CIDR. In my opinion one should reduce the number of routes, not make it easier to maintain large amounts of routes. And do bear in mind that what we do on this matter does not have the slightest effct on the real world unless we make ANS implement the changes in their software. Hans Petter
In message <9510211419.AA25411@banknet.banknet.net>, Janos Zsako writes:
From owner-db-wg@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
Hi Curtis,
Curtis Villamizar writes:
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.
Merit has a version of the radbserver which implements some of the fixes that ANS has proposed. ANS generously provided patches for using the radbserver with perl4 and db, but the radbserver is running under perl5. That slowed down the adoption of the fixes. --Elise
To sum up: ANS is not going to use advisories in aut-num since they will do away with advisories in at most two weeks. The advisory attribute will stay in aut-num objects and we all hope noone is going to use them again, ever. Daniel
participants (6)
-
Curtis Villamizar -
Daniel Karrenberg -
David.Kessens＠ripe.net -
Elise Gerich -
Hans Petter Holen -
zsako＠banknet.net