Death of irrtoolset?

Kevin Oberman oberman at
Sun Oct 11 00:01:22 UTC 2009

> Date: Sat, 10 Oct 2009 16:46:54 -0700 (PDT)
> From: Jonathan Day <imipak at>
> Sender: irrtoolset-bounces at
> --- On Fri, 10/9/09, Nick Hilliard <nick at> wrote:
> > From: Nick Hilliard <nick at>
> > Subject: Re: Death of irrtoolset?
> > To: "Faidon Liambotis" <paravoid at>
> > Cc: irrtoolset at
> > Date: Friday, October 9, 2009, 11:02 AM
> > On 09/10/2009 16:38, Faidon Liambotis
> > wrote:
> > > All in all, I don't understand this sudden change of
> > heart.
> > > Could you please give more details about your plans,
> > especially
> > > regarding ISC's position on this?
> > 
> > Please excuse the melodrama in that talk.  It was the
> > first talk of the day after a well-attended social from the
> > night before, and I deliberately set out to provide a
> > modicum of entertainment, so perhaps it would be useful to
> > explain my position.  It is this:
> > 
> > The code is unmaintainable.  Completely and utterly
> > unmaintainable.
> (snip)
> Ok, so maintaining the existing codebase is impossible. Where does that leave us?
> Rewriting the entire toolset from scratch is going to be hard work and I sincerely doubt that there'd be a whole lot of funding for it. The "if it works, don't fix it" mindset is superbly honed in the minds of bursars and CFOs when it comes to asking for funds for such projects.
> On the other hand, is there an actual need to replace the entire toolset in one go? So long as none of the applications is completely broken, it would seem to make sense to roll gradually from what's there now to irrtoolset-the-next-generation.
> One option would be to start by writing placeholder apps with the interfaces you want that initially do nothing more than call the existing apps and regurgitate the output. It doesn't matter that some tools will use the old, unmaintained code and some tools use the newer code, because as long as the old code works, there shouldn't be any huge difference. Let the code naturally roll over from the old to the new via user-contributed patches.
> A second option is to spec out the APIs, library structure, etc, and do an ISC "winter of code" (as a play on Google's "summer of code"). Consider this - more students are looking for final-year projects and Masters material to use over Fall/Winter/Spring than are looking over summer. And undergraduates are essentially free. (The only thing you're paying for is your time to check to see if their code is usable.)
> A third option would be see if you can get help on this. Ubuntu and Red Hat have coders aplenty and serious financial muscle. OpenBSD needs network tools that are bulletproof, and irrtoolset (as it stands) is clearly not that. The US Government is pushing cybersecurity, but you can't have that if fundamental tools aren't secure. Japanese ISPs were major sponsors of IPv6 development - for code and cash, perhaps they'd be willing to provide some help with this. Sweden is also highly connected and must therefore have a need for good backbone support tools.
> The shortage would not appear to be in the number of options you can shoot for, the shortage would seem to be in what you can do without calling in the heavies.

As Pekka Savola suggested, take a look at RAS's IRR Power Tools (IRRPT) at It is not a full RPSL
implementation, but it does a lot of the things IRRToolSet does in code
that can actually be read.

I worked with the author on porting the RAToolSet (original name of
IRRToolSet) to Tru64 on the Alpha and I found the code about as opaque
as could be imagined and the licensing makes it effectively useless to
commercial users.

Take a look at IRRPT and see if it will do what you need to do or if you
can add functionality to it.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

More information about the irrtoolset mailing list