Follow up to previous post regarding SAAVIS

Joe Maimon jmaimon at
Thu Aug 13 09:07:29 CDT 2009

Richard A Steenbergen wrote:
> On Wed, Aug 12, 2009 at 04:57:07PM -0400, Jared Mauch wrote:
>> I've come to the conclusion that if someone put a nice web2.0+  
>> interface on creating and managing these objects it would be a lot  
>> easier.
> Agreed, this is one of the projects I've been working on just haven't 
> had the time to finish it. But please allow me to put in a shameless 
> plug for IRR PowerTools, which many networks (including a couple tier 
> 1s) use to do their IRR:
> The highlights are:
> * Automated retrieval of prefixes registered behind an IRR Object.
> * Automatic exclusion of bogon or other configured undesirable routes.
> * Tracking and long-term recording of prefix changes over time.
> * Automatic aggregation to optimize data and reduce unnecessary changes.
> * E-mail updates, letting users know that their change was processed.
> * E-mail alerts to the ISP, letting them know of new routing changes.
> * E-mail alerts to non-IRR using networks, with plain text changes.
> * Router config generation, for easy automated config deployment.  
> I'm also in the process of beta testing a new 2.0 version which will be
> significantly rewritten for easier more scalable use, have a lot fewer
> dependencies, integrate better with db backend systems to customer
> prefix-list management, and fully support IPv6. Oh and there might just
> be a web gui for managing and using it too, if I can find a decent web
> developer who will do it for free. :) I'm hoping to have this out in the 
> next couple of months.

The longer a network develops without using or maintaining IRR data, the 
more difficult the transition becomes. A truly awesome capability would 
be to have some way to slurp in current configuration and output IRR 
objects that can then generate a functionally identical configuration.

Even without that, I would happily settle for any improvements to irr 
tools, powertools or toolsets. I am sort of disappointed that there 
seemed to be far less then deserved support from those with a stake in 
this, the registries and vendors.


More information about the NANOG mailing list