Death of irrtoolset?

[Nick Hilliard]

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.

It is a tangled mess of irreconcilably licensed C++ libraries.  It is an 
inheritance nightmare, with all sorts of objects pretending to be all sorts 
of other objects, and no documentation whatsoever about how they are linked 
together and how they should be used or anything.  The class structures are 
built such that debugging of any sort is almost impossible using gdb.

Internally, there is virtually no library / api or even coding style 
consistency.  There are two separate error management systems, and strings 
are variously managed using nul-terminated c strings, stringstream and a 
variety of other libraries.  iostream is horribly overloaded.  Operators 
are overloaded all over the place and you just have no idea what they're 
doing.  Same thing with iterators.

Adding to the code is very difficult indeed, and almost nothing can be 
trivially done.  I'll stick my hand straight up and say that I'm not a c++ 
coder, but I've been playing around with computer programming for long 
enough to know what you should or shouldn't be able to do or understand, 
stared at code for a given time period.  But the internals of irrtoolset 
are still completely opaque to me.  Maybe it needs smarter people than me 
to work on it - like Cengis or Katie.  But they cost lots of money and I 
don't have lots of money to pay them.  Nor does the RIPE NCC or ISC.

Also, the code may not be used for commercial purposes, according to the 
licenses.  In particular, the re2dfa license is dually owned by IBM and 
ISI, and this code is critical to rpsl regexp management.  Outside academic 
and not-for-profit institutions, this means that you are simply not allowed 
to legally use it.  This alone is crazy.  It doesn't affect me or you, but 
it affects the majority of people who are interested in using RPSL for 
their policy routing management.

I've no idea how to get the licensing changed.  I seriously doubt that IBM 
have any knowledge of their I.P. interest in the code, and I suspect that 
the re2dfa lib was snatched from some weird version of gated without their 
knowledge anyway. ISI, being an academic institution could go either way. 
Some halls of academia are quite reasonable about licensing their code; 
others see all I.P. as a potential cash cow.  I have no idea which way ISI 
would go on this.

As one person at the talk later noted, irrtoolset is a great example of a 
project which was designed by someone who was clearly incredibly smart and 
which would lead to a fine grade in a master's or even a phd thesis. 
However, it is just not suitable for release as a maintainable production 
package.

My take on it is this: 5.0.0 is tagged as r300 and is about ready to be 
released.  I need to check it out on some platforms first before getting 
ISC to put it up on their ftp site.  But as far as I'm concerned, there is 
so much wrong with the current code base that it would be a lot more useful 
for all concerned to develop a sensibly licensed rpsl client library using 
a sensible scripting language which has easy-to-use template libraries 
(perl springs to mind for a variety of reasons, not least because of 
Template::Toolkit and lots of other really useful goodness on CPAN, but I'm 
open on this).  librpsl isn't massively cpu intensive and doesn't need 
bare-bones C speed.  A scripting language should do the job fine.

As I said in my talk, INEX has ridiculously large router configurations 
even though we're a small exchange, and there is simply no way that we can 
manage them manually.  We need a tool like rtconfig, but we also need a 
tool which can do more than this, and which can be made much more flexible. 
  Right now, there is no flexibility, not least because the strongly typed 
nature of C++ means that adding anything means all sorts of crawling around 
on your hands and knees doing stuff that it trivial in loosely-typed 
scripting languages.

I also believe we need to revisit RPSL/RPSLng.  But that's a separate 
issue.  The pdf of my talk on the ripe web site doesn't include the actual 
stats, but the distribution of objects in the ripe DB is:

inetnum, 2751953
domain, 450991
route, 109857
inet6num, 28114
aut-num, 18837
as-set, 8772
key-cert, 5769
as-block, 2147
route6, 1210
route-set, 895
peering-set, 169
inet-rtr, 113
filter-set, 90
rtr-set, 14

Many of these objects are quite stale.  Figuring out how stale is an 
entirely different matter, but the point is that most of the more advanced 
features of irrtoolset/rtconfig and rpsl are barely used.

I'm not going to do a whole lot more on this code base.  If someone reports 
a bug, I'll certainly take a look at it, and if someone asks a question, 
I'll do my best to reply.  But any time I get to spend on rpsl / client 
policy routing is going to be spent on a rewrite, starting out with the 
most useful and used features and leaving a framework for the less used 
stuff in rpsl.

I don't know what the RIPE NCC's position is on this, or whether they have 
a position.  ISC do not have the resources to put a whole lot of effort 
into the project.  They'll happily host it, though.  Other than that, any 
individual that I've talked to with knowledge about the internals of 
irrtoolset has agreed that it's not worth pursuing in its current form, but 
that it could be worth pursuing in other forms.  If I get some time, I 
would like to explore this option.

Nick