Death of irrtoolset?

[Matthew Moyle-Croft]

Just to add my 2c.

We do actually use RPSL to control routing policy from an internal  
whois DB.  It may not be pretty but it does mean we have no hand  
configured ebgp.

We don't do particularly complex things:

- AS-SET filtering / private IP space filtering
- Filtering based on particular AS paths
- Mapping advertisements to communities etc
- Controlling customer advertisements.

Aside from 32bit AS support (latest version may have it but we haven't  
tried properly) I don't think there's much we need doing - at some  
point I'd love to see IOS XR support.

MMC

On 11/10/2009, at 10:31 AM, Kevin Oberman wrote:

>> Date: Sat, 10 Oct 2009 16:46:54 -0700 (PDT)
>> From: Jonathan Day <imipak at yahoo.com>
>> Sender: irrtoolset-bounces at lists.isc.org
>>
>> --- On Fri, 10/9/09, Nick Hilliard <nick at inex.ie> wrote:
>>
>>> From: Nick Hilliard <nick at inex.ie>
>>> Subject: Re: Death of irrtoolset?
>>> To: "Faidon Liambotis" <paravoid at debian.org>
>>> Cc: irrtoolset at lists.isc.org
>>> 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
> http://sourceforge.net/projects/irrpt/ 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 es.net			Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
> _______________________________________________
> irrtoolset mailing list
> irrtoolset at lists.isc.org
> https://lists.isc.org/mailman/listinfo/irrtoolset