I suppose this is an issue of level of automation desired. The more expects of the policy configuration you let RtConfig handle, the more helpful it is. The more routers there are to configure, the more helpful it is, since the task is per AS as opposed to per router. As one provider once said, it rationalizes policies... It is being used by many ISPs, and is a mature technology. I understand that the level of policies that need to be published is viewed to be too much by some ISPs. We put hooks so that not all have to be made public anymore (some can come from privately held objects). We also made it easier for folks to generate just "prefix lists" from IRR and nothing else. For this, many either use RtConfig's "access_list" command (as opposed to import/export) or wrote their wrappers around peval. Apart from this, I would like to hear your feedback on RtConfig so that we can use it to improve it, perhaps in a private email. Jason Lixfeld (jlixfeld@team.look.ca) on May 15:
Morning, world :)
Over the last little while I've brought up an IRR server and have installed into it, and updated all of our information which was previously stored in other IRRs (BTW: Thanx to everyone who replied with human contacts for the CW and ANS irrs).
Everything is up to date and ready to go. Now I can start on the config generation part of the process. I started looking into @RtConfig but am not too happy with it. I've heard that others have found the same thing and have fabricated their own ways of extracting information from the IRRs and inserting them into their routers. I'm wondering if people could share any of these with me so I can work on creating my own tool.
TiA.
Regards, -- Jason A. Lixfeld Senior Network Engineer Look Communications Inc. (V.LKC) --
Cengiz -- Cengiz Alaettinoglu Information Sciences Institute http://www.isi.edu/~cengiz University of Southern California