Over the last couple of weeks, a group of people using the RIS (data) decided to hold a phone conference in order to discuss future development plans for the RIS as well as other things, that were hard to discuss by email. Below you can find the minutes of this meeting. We agreed to post the minutes of this meeting here, so everybody can see what we discussed. If you have comments on our discussion, feel free to post them to this list. We agreed to hold another phone conference in a couple of weeks. This will be an open forum. If you want to participate in future phone conferences, please send mail to ris@ripe.net and we'll provide you with technical details. Comments, suggestions and ideas by email to ris-users@ripe.net are also welcome. Regards, James -- James Aldridge, Network Engineer, New Projects Group, RIPE NCC Tel: +31 20 535 4444 Fax: +31 20 535 4445 Singel 258 P.O. Box 10096 1016 AB Amsterdam 1001 AB Amsterdam The Netherlands The Netherlands ---------- Notes on the RIS conference call 18:00 CET, 16 October 2003 Participants: RIPE NCC: Henk Uijterwaal, James Aldridge, Matthew Williams, Arife Vural, Lorenzo Colitti, Rene Wilhelm; Agilent: Alex Tudor, Lance Tatman, Jerry McCollom, Hong-Wei Kong; Technical University Munich: Olaf Maennel Dan Ardelean (Purdue) and Z. Morley Mao (Berkeley) provided input but were unable to participate in the conference call. Scribe: James Aldridge Agenda: 1. RIPE NCC "ip2asn" service 2. Zebra/Quagga and libbgpdump 3. Beacons 4. CVS server 5. BGP decoder 6. Keepalive issues 7. Future merge with zebra 1. ip2asn Rene Wilhelm gave an update on the current status: - nearing completion - raw data read from 8-hourly RIS RIB dumps - structure built in memory - "whois" server returns a (partial) RPSL "route" object for compatibility with existing RIR-based tools. Is this sufficient? OK as a first try, but want more... summarise traceroute as AS hops, etc. This would be for the traceroute application to perform; ip2asn just provides a BGP-based mapping between IP address and origin AS(es). Is there a demand for a standalone IP to ASN server returning additional information (incorporating database of IXP address ranges, etc)? Rene will provide sample output from the current ip2asn server. 2. zebra, libbgpdump Lorenzo Colitti presented an update on changes to libbgpdump and zebra (/quagga). - bug fixes - dealing with data corruption - segmentation faults - infinite loops - IPv6 support - direct gzip support (using zlib) Importance of multi-platform support was emphasised (make it easy to build on more systems than just FreeBSD, Linux, etc.; use "sh ./configure", etc) Need a test plan for future changes: - test data (known input) - regression testing on output produced Need to document library's behaviour for specific cases of bad input data. Needs to report back statistics from processing input file (in Hong Wei's version?) Summary of libbgpdump-1.3.1 - backward compatible for input data - baseline release for further integration Aim towards a replacement for "route_btoa". 3. beacons James Aldridge summarised recent changes to the RIS BGP beacons following input from the research community - timestamps and sequence numbers on announcements by overloading the AGGREGATOR attribute (similar to the PSG beacons) - anchor prefix (195.80.239.0/24) advertised by each RRC with per-RRC AGGREGATOR values. Proposal to monitor RIS beacon announcements and withdrawals using an additional bgpd with multi-hop EBGP peerings with each RRC was greeted with interest. James will implement this and make the beacon reference updates alongside other RIS raw data. - Proposals from Z. Morley Mao: "(1) Would it be possible to put a host behind a few beacon prefixes, so that application layer traffic measurements can be conducted to study how data plane is affected by routing changes? If bandwidth is a concern, one can rate-limit the incoming pipe of those hosts." Technically, it wouldn't be too difficult to add a dummy interface with appropriate IP addresses on each RRC. However, the current agreement with peers and RRC hosts is that there will never be any (non-BGP) traffic to the RRCs. "(2) Could you instrument failover scenarios for multihomed beacons, i.e., announce withdrawal to all but one of the upstream provider to study how long it takes to switch over to backup provider?" RIS team will investigate this. 4. cvs server Henk Uijterwaal summarised the current status of the RIPE NCC providing a public CVS server for NCC-developed software. - Other groups within the RIPE NCC also want this - Being set up - Requirements and specs done - Now in the hands of RIPE NCC Ops group. - Waiting for security sign-off - Probably two to three weeks. In the meantime we can exchange tarballs and patches. 5. BGP Decoder Covered in 2 above. 6. Keepalive issues Problems with missing keepalive messages from Zebra had previously been seen only under Linux and it had been thought that FreeBSD was immune to these problems. However, recent tests show that FreeBSD also exhibits the same problems. Removing "unnecessary" routines from Zebra bgpd solves the problem but at the loss of required functionality. Is this problem caused by an overloaded system or a more structural problem in Zebra even on faster or more lightly loaded systems? This needs to be investigated. Can we come up with system requirements for reliable operation for BGP collection for different setup sizes? (e.g. XXX Mhz processor, YYY Mbytes RAM, etc. for NNN full BGP feeds) 7. Future merge of Zebra/Quagga work Getting patches incorporated into quagga seems much easier than was the case with Zebra. Document results of tests and submit to quagga-dev. Need to dump outgoing updates. Currently bgpd only dumps received updates and we miss outgoing error responses, etc.