About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: Proposal on applying advisory attribute to "aut-num" object

  • To: (Janos Zsako)
  • From: Curtis Villamizar < >
  • Date: Mon, 23 Oct 1995 14:03:54 -0400
  • Cc:
  • Reply-to:

In message <9510211419.AA25411@localhost>, Janos Zsako writes:
> >   From owner-db-wg@localhost 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




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community