RIPE 57

29 October, 2008, 13:30 - 15:00

Chair: Joao Damas
Minutes: Chris Buckridge (RIPE NCC)
Jabber Scribe: Mark Dranse (RIPE NCC)

A. Administrative Matters

The Chair added an agenda item following Agenda item B.

The minutes from the RIPE 56 Meeting were approved.

B. IRRToolset Developments
Shane Kerr, ISC

The speaker outlined the IRRToolset, its history and its recent transfer to the public domain. He encouraged everyone to participate in the ongoing maintenance and development of the IRRToolset using the Trac site that has been set up.

Erik Romijn (RIPE NCC) asked when/whether the IRRToolset would support 32-bit ASNs. Shane noted that there are patches, but he has chosen not to merge them, and that this is listed as an action item for the community. Ruediger Volk noted that there are several proposals for patches, but if the RPSL notation is changed, this will have some influence, and there needs to be thought given to what "support" means - it depends whether you are generating code for an "only 16-bit" system or for all.

Erik also asked about the ISC procedures that are in place to protect data quality. He noted that there is no documentation of the internal architecture of the toolset, and asked if there is a way to get some documentation on this. João noted that such documentation was never on the "to do" list for ISC, but that ISC had committed to wrap up all work to date into a workable version; all subsequent work will be done by the community, not ISC. ISC will ensure that the project remains accessible, and release subsequent releases as and when they arise, but the community must produce these versions.

Shane also noted that others are welcome to take issues raised on the mailing list and include them on the development website.

Andrei Robachevsky (RIPE NCC) noted that RIPE NCC has been involved in sponsoring this project, and commended it as a success.

B2. Policy proposal on use of RPKI certificates for the use of RPSL objects.

This issue was raised at the last RIPE Meeting, and directed to the Routing Working Group. The working group needs to collect some data on this, for which a small, focused group is required. BBN and the RIPE NCC have already done some work in this area.

João suggested the formation of a task force to look at this issue, and report back over the next 2-3 meetings on what the RIPE NCC should be doing to address this need. Members are sought for this task force, especially people with an understanding of RPSL and RPKI.

Ruediger noted that there are two implementation options. The first, which applies to the RIPE Database server, has been drafted by Andrei Robachevsky (RIPE NCC). Some output from this was demonstrated at the recent IETF meeting. The other option is better for people who want to do validation of data themselves - it is being looked at by BBN and seems to be going well (it is now close to completion).

Randy Bush noted the proposal put forward by himself and Curtis, and that there is starting to be code run. This "quick hack" option is meant to get things going, filling in the gap for the time needed to develop the complete solution. It should therefore not become the subject of overly intrusive bureaucracy, study groups, etc.

Andrei noted that at first the NCC option looked like a simple hack, but it got very complicated, and there are now two options - a quick, simple hack with limitations or a bigger picture approach; that is, are we trying to improve the security of the Internet Routing Registry using RPKI?

Randy Bush noted that his proposal is very much in favour of the quick hack.

Ruediger concurred that this should be a quick hack, but noted that this will provide some very early incentive for populating the RPKI, which will help speed up the real solutions if they come in quickly.

João noted that the task force structures in RIPE are very lightweight. Geoff Huston, Ruediger and João volunteered to participate in a task force, as did Andrei (acting as RIPE NCC contact). João will facilitate the task force activities.

C. Toolset Tales from the 4-byte ASN Frontier
Dave Wilson, HEAnet

The speaker outlined his experience using a 32-bit ASN, specifically problems that he had encountered with relation to IRRToolset users. He had found that the RIPE Database neatly accepted 32-bit ASNs but that the IRRToolset is not capable of processing them, which has resulted in wrong configurations. He noted that the proposed ASPLAIN format being discussed in the IETF and elsewhere would be useful.

Gert Doering thanked Dave for the experiment and feedback, and noted some similar experiments that his company has done. Gert noted that it has been suggested that AS-DOT is bad because it is incompatible, but that he feels it is a good idea for specifically this reason.

Ruediger noted some improvements that he has already made to IRRToolset that avoided the issues that Dave had run into with his upstream. He also responded to Gert's comment finding that their scripts and IRRToolset had created erronous configuration data, and noted that as a consequence he applied manual fixes in his tools. He then asked for support to get the IRRToolset to handle things correctly in order to get these to become production tools.

Lorenzo Colitti asked why Dave didn't simply announce two prefixes, rather than flipping a coin and switching the prefix.

Henk Uijterwaal (RIPE NCC) noted that he and Katy Petrusha (RIPE NCC) had written a draft on what would need to be changed in RPSL code when moving to 32-bit ASNs. This has been held back while discussions happen, but it might be time to move forward with it.

João asked the RIPE NCC whether they would incorporate ASPLAIN fairly quickly now that it seems to be accepted. Andrei noted that the NCC wishes to be in line with the IETF, so yes. But he noted that there is no flag-date for when to stop issuing non-32-bit ASNs.

D. IPFRR and the Principle of Simplicity
Clarence Filsfils, Cisco

The speaker described some analysis that shows how most of the benefits of IP Fast Reroute can be achieved from simple configurations. The analysis showed that convergence times of x00 msec is possible, where x = small single digit.

There was no further discussion of the presentation.

E. MyASN
Franz Schwarzinger, RIPE NCC

The speaker gave an update on recent improvements to the RIPE NCC's MyASN software.

There was a question about DNSMON alarms, and when they will be available. Franz noted that they are already active, and use the same format as MyASN. The questioner also noted the a five-minute delay is not "live", and asked whether it will eventually be made more "live". Franz noted that work is underway, and that the the development team hopes to get to real time. The questioner also suggested Jabber as a useful notification system.

Y. I/O with Other Working Groups
No discussion.

Z. A.O.B.
There was no further business discussed.