RIS developments

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 at ripe.net and we'll provide you with technical details.
Comments, suggestions and ideas by email to ris-users at 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.