- db-wg - mailman.ripe.net

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 26 Jul '93

26 Jul '93

> One of the ideas we talked about was to go to a structure like > > NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) > RIPE-XY999 (newly assigned within the RIPE community) So you end up with data like : person: Duncan Rogerson . . handle: NIC-DR222 handle: RIPE-DR001 (assuming multiple handle: fields are permitted, to cope with people who for one reason or another have both types of handle). or person: A Person . . handle: RIPE-AP001 .. in the database ? Or should the name of the field distinguish between RIPE and NIC handles - ie the person object can have two fields, nic-hdl: and ripe-hdl: to cope with people who end up with a handle of each type. Dunc

2 1

Unique NIC/RIPE/xxx-Handles
by Wilfried Woeber, UniVie/ACOnet 23 Jul '93

23 Jul '93

Dear DB-folks, during the IETF we (Daniel K, Ruediger V and me) had a short ad-hoc meeting and identified some aspects of the RIPE-DB business that should be addressed and discussed. One of them, and quite urgently needed is to agree on structure and procedures to obtain unique handles for people who do not (yet) have NIC handles. One of the ideas we talked about was to go to a structure like NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) RIPE-XY999 (newly assigned within the RIPE community) Reudiger even thought about adding even more structure like RIPE-Provider_ID-XY999, or RIPE-XY999-Provider_specific... The issue here is whether we want to have the Provider_ID as part of the hierarchy tree. My personal preference is the RIPE-XY999[-optional-Provider_specific...] format, the handle being unique without the Provider part. Another question is where and how to register/assign these handles. One possibility could be to have this as a service from and at the NCC, say assigned by some script. A Different approach would be to assign them somehow at the Local-IRs. Could you please comment on these? I'd like to have some form of consensus ready for approval at the next RIPE meeting. Best regards, Wilfried.

1 0

Re: EU.net and eu.net database entries
by RIPE NCC Staff 23 Jul '93

23 Jul '93

Piet.Beertema(a)mcsun.EU.net writes: * A day or so ago I submitted a new entry for the EU.net domain, * meant to be a change on the current entry. However, I denoted * it as "EU.net" (which is the official name) instead of eu.net. * Now it appears that the updating software saw this as a *new* * entry rather than an update, in other words it doesn't work * case-independent. On the other hand the database query s/w * does work case-independent, so "whois eu.net" now gives me * two entries... * Could you remove the old eu.net entry? I dare not submit a * change for it to get it deleted, in case the updating s/w * decides to start working case-independent in that case... Sorry Piet, old, old, old software ... The new software will take care of this, but I think the new software will change everything to lowercase. I have not written this part yet, have to put some thought in it though. Anyone in the database working group has any feeling how these should be dealt with ? From a programming point of view, handling everything lowercase is much easier, I do not really want to check every single combination of lower/uppercase before I update something ... Then again, after some thinking (I usually type faster than I think ;-) the indexing is done in lowercase, and key lookups are always normalized to lowercase before a lookup. So the real question is, should entries in the database be left untouched when it comes to upper/lowercase, or should all be normalized ? -Marten

2 1

Re: EU.net and eu.net database entries
by craig＠icm1.icp.net 23 Jul '93

23 Jul '93

> (I usually type faster than I think ;-) the indexing is done in lowercase, > and key lookups are always normalized to lowercase before a lookup. > > So the real question is, should entries in the database be left untouched > when it comes to upper/lowercase, or should all be normalized ? since all is normalized to lowercase before a lookup i think it is OK to have the database show things in capital letters as long as everyone knows all is treated as lowercase. summary: o view as is stored in the database o normalize before performing other operations on the database. craig

1 0

Re: EU.net and eu.net database entries
by Wilfried Woeber, UniVie/ACOnet 23 Jul '93

23 Jul '93

Marten, >Sorry Piet, old, old, old software ... The new software will take care of >this, but I think the new software will change everything to lowercase. I >have not written this part yet, have to put some thought in it though. > >Anyone in the database working group has any feeling how these should be >dealt with ? From a programming point of view, handling everything lowercase >is much easier, I do not really want to check every single combination of >lower/uppercase before I update something ... Then again, after some thinking >(I usually type faster than I think ;-) the indexing is done in lowercase, >and key lookups are always normalized to lowercase before a lookup. > >So the real question is, should entries in the database be left untouched >when it comes to upper/lowercase, or should all be normalized ? I'd prefer the following behaviour: - In the external representation keep it exactly as it was submitted, with mixed case intact. - Internally, whenever you use this string for an index, compare or lookup, consistently convert it to lowercase, thus prohibiting duplicates with different case. I think this would even be in line with the current behaviour of other programs... I don't have any idea what this would mean to the implementer programming-wise... Wilfried.

2 1

New database software update
by Marten Terpstra 24 Jun '93

24 Jun '93

all, It's time to let you know what has happened wth RIPE database software development. After some more experimenting to check feasibility we have progressed quite far into a complete rewrite of the database software. We have completed the system design and started to implement various modules. The new design has the following features - fully (and we *mean* fully!) configurable from a config file - separate files (and indices) to store different databases - dynamic updates and deletes as opposed to batch only - possibility for update protocol other than e-mail - guarded fields designed in - dynamic update of secondary databases possible Features which have been requested but are not designed in: - preserve the order of tags within object - preserve the position of remark or comment lines within objects These two features turned out to be hard to specify in the light of updates and even harder to implement. They might go in the next release if someone can come up with a consistent and intuitive spec. The new software will be implemented in the perl language. So those of you who do not have it installed and want to use the RIPE database software should plan to install perl. Of course you won't need perl if you just want to use a whois client and send in updates by mail. Implementing in perl instead of shell, awk and C has three benefits: coding in perl ist fast, subroutines can be used (missing from std awk) and the result is portable. We have a copy of the alpha software running on a PC under UNIX. Together with a notebook this gives you a "portable" RIPE database. The first module completed is the whois server (net.c and netdbm.c replacement). This server runs as its own daemon process rather than under inetd. The measured performance on a SUN ELC before optimising is 5 queries/s on average and the server can sustain peaks of 50 queries arriving in parallel. The new server is compatible with the current one and has some added features: the source databases (RIPE, MERIT, NIC etc.) can be selected individually rather than either RIPE or all, the same connection can be used for multiple queries (nice for tools like prtraceroute), a grep type query as well as nice logging. We have an alpha version of the whois server and the database indexing tool running. The next part to be tackled is the update procedure including the guarded attributes. The last part will be the current mail interface for the update procedure. Impact: Sometime in the next few weeks (after another announcement) we will start using the new server on whois.ripe.net. This should be transparent. Once this is running we will implement the backlogged new tags such as the DMZ specifics in the network and the operatinal contacts. Sometime later we will start using the new update procedures. This will mean that updates mailed in will appear in the database more quickly. It will also mean that we will be more stringent in checking updates, because there will be less human intervention from NCC staff. So you should expect more bounced updates, but they will also happen much more quickly. Diagnostics will be better because the dynamic update procedure will have access to the current database. This will mean that heuristic checks of updates can be better. If you have any questions, please do not hesitate to ask them either puclicly for the benefit of all or privately. The NCC people working on this are me (design, coding and testing) and Daniel (design and testing). Cheers, -Marten

1 0

RIPE whois server
by Marten Terpstra 16 Jun '93

16 Jun '93

Dear people, I am currently working on a new whois server and update procedure and would like to know if there are any additional features you would like to see in the server (I'll leave the update procedure for now, still too early to talk about features). I have rewritten de whois server and the index program in Perl, and have a prototype running (not the production server). I have made the following changes: - database objects are *completely* configurable from a configuration file - this means the indexer follows this file to look for keys - the server follows this file for recursive lookups - multiple databases can be served, all seperately indexed, and kept in seperate files (with the same object structure though) - databases can be indexed at different times - all configurable from config file. - additional functionality in the server - "-s SOURCE" flag to ask the data from specific source (in the prototype "RIPE", "MERIT" and "INTERNIC") - default SOURCE configurable in config file - all SOURCES ("-a" flag) configurable in config file - "-g" option to indicate an object "grep" for a certain string, in stead of the normal key lookup (running low priority - slow) - able to handle more queries/sec (no longer running out of inetd) - an option to keep a connection to the server open, for multiple queries fast after each other. (esp useful for applications like prtraceroute) Any other features you always wanted to have in the server ? Now is the time to make them known, so that we could incorporate them. If you want to have a go at the new server, it is running on rijp.ripe.net on the normal whois port (no uptime guarentees). One thing is that the new flags (-g and -s) do not work with the RIPE whois client ;-( An old client with the flags inside quotes should work. Oh, just remembered, -g is not implemented yet ;-) The data in the prototype server is a bit outdated (last weeks databases or so). so, with an old client you should be able to say: whois -h rijp.ripe.net "-s ripe marten" whois -h rijp.ripe.net "-s merit 192.87.45" whois -h rijp.ripe.net "-s internic mt2" whois -h rijp.ripe.net "-a 192.87.45" You can give it a stress test if you wish, we have done the same, and could not make it crash yet (we did 50 parallel sessions of 10 sequential queries each) A little bit on the update procedure, we are implementing an "on-the-fly" update procedure, that is, no "once-a-day" updates, but updates are processed and incorporated in the running database (and whois server) immediately when they come in. This would mean that (because there will be no manual intervention any longer) that more updates will be bounced because of syntax errors, but you get the bounces fast ;-) Then once a day the guarded tags will be added at a set time. They will be ignored during the normal updates. Please do not nag too much on the update procedure yet, it is still in a "pre-pre-pre-prototype" stage. So, so much for a quick update, if you have suggestions, please let me know. -Marten

1 0

Description of Inter-AS Networks in the RIPE Routing Registry
by Daniel Karrenberg 08 Jun '93

08 Jun '93

Friends, here is the proposal on how to solve the prtraceroute problem as discussed in the last routing-WG meeting. Could we have comments until May 17th please! I'll circulate new versions as substantive comments are incorporated. The goal is to have the database capable of storing this a.s.a.p. and have some data in there quickly as prtraceroute is released. Note that this is not only useful for prtraceroute but much more generally. It could also be the start of the local inter-AS connection information dicussed in the last routing-wg meeting too. As such this addendum could be extended. Proposals ? Cheers Daniel Description of Inter-AS Networks in the RIPE Routing Registry Tony Bates Daniel Karrenberg Addendum to Representation of IP Routing Policies in the RIPE Database (ripe-81) What is an Inter-AS Network ? Inter-AS IP networks are those networks which connect multi- ple autonomous systems (1). An inter-AS network exists for the purpose of passing traffic and routing information between different autonomous systems. The most simple exam- ple of an inter-AS network is a point-to-point link, con- necting exactly two ASes. Each end of such a link is con- nected to an interface of router living in each of the auto- nomous systems. More complex examples are broadcast type networks with multiple interfaces connecting multiple ASes with the possibility of more than one connection per AS. Which additional information is needed? Consider the following example of three routers 1, 2 and 3 with interfaces a through f connected by two inter-AS net- works X and Y: X Y a1b --- c2d --- e3f _________________________ (1) Inter-AS networks are currently called FIXes, IXFs, DMZs, NAPs, GIX and other names. - 2 - Suppose that network X is registered in the routing registry as part of AS1 and net Y as part of AS3. If traffic passes from left to right prtraceroute will report the following sequence of interfaces and ASes: a in AS1 c in AS1 e in AS3 The traceroute algorithm enumerates only the receiving interfaces on the way to the destination. In the example this leads to the passage of AS2 going unnoticed. This is confusing to the user and will also generate exceptions when the path found is checked against the routing registry. For operational monitoring tools such as prtraceroute it is necessary to know which interface on an inter-AS network belongs to which AS. If AS information is not known about interfaces on an inter-AS network, tools like prtraceroute cannot determine correctly which ASes are being traversed. Proposed Format All interfaces on inter-AS networks will be described in a new ias-int attribute of the corresponding network object in the RIPE database. The ias-int attribute has the following syntax: ias-int: <interface-address> <autonomous-system> The <interface-address> must be an address within the corresponding intenum and <autonomous-system> must be of the form AS<number> refering to an aut-num object in the data- base. - 3 - For example: inetnum: 193.193.193.0 netname: INTER-AS-EXAMPLE descr: This is a hypothetical inter-as network. descr: It might be called a NAP, FIX, GIX, IXF, DMZ, descr: Mehrfachdienstanbieterkommunikationseinrichtung or ... country: DE admin-c: Werner Mueller tech-c: Paul Schmitz tech-c: Hans Meier changed: ripe-dbm(a)ripe.net 920714 aut-sys: AS4711 ias-int: 193.193.193.1 AS123 ias-int: 193.193.193.3 AS4711 ias-int: 193.193.193.9 AS789 source: RIPE Note that the interface 193.193.193.3 is described although it is in the same AS as the network. This is recommended practice. The update procedure for the ias-int attribute will be the normal update procedure for network objects. The attribute does not need to be guarded because it does not influence routing policy of operational traffic. In which AS does an Inter-AS Network belong? Only one AS announces an inter-AS network externally. The other ASes connected to the inter-AS network will probably carry this network in their internal routing for redundancy but will not announce it to other ASes. In exceptional cases more than one AS may need to originate external routing information about the inter-AS network, This kind of routing setup cannot be described within the framework of ripe-81 and is generally discouraged. Tools using a ripe-81 type registry could take heuristic hints from the ias-int attributes when they encounter such situa- tions.

3 6

Mail archive
by Marten Terpstra 14 May '93

14 May '93

Folks, We have created an archive of all mails that go over the db list on ftp.ripe.net:ripe/archives/db Current directory contents: % ls -lg ~ftp/ripe/archives/db total 128 -rw-r--r-- 1 marten staff 2163 May 14 15:58 db.Apr-93.Z -rw-r--r-- 1 marten staff 30977 May 14 15:58 db.Feb-93.Z -rw-r--r-- 1 marten staff 5416 May 14 15:58 db.Jan-93.Z -rw-r--r-- 1 marten staff 65481 May 14 15:58 db.Mar-93.Z -rw-r--r-- 1 marten staff 9896 May 14 15:57 db.Nov-92.Z -rw-r--r-- 1 marten staff 13376 May 14 15:55 db.Oct-92.Z -Marten

1 0

RIPE database on ftp.ripe.net
by Marten Terpstra 12 May '93

12 May '93

db and routing gurus, Since there have been people complaining about the size of the database that they need to transfer every day to just update their access-lists, we have made a little script that will split the database into several pieces, one file per object type in the database. This script will run every night at 20:00, so please make sure that if you retrieve one of these files that you do it after 20:00. We did not want to add it to the update procedure of the database straightaway, since that is already overloaded with side effects. Please check the date on the first line if you are not quite sure you have the latest copy. The date line and copyright notice have been copied to all seperate files. The seperate files can be found on ftp.ripe.net:/ripe/dbase/split. Below is the current directory contents. All files are compressed, but since our ftp server compresses and uncompresses on the fly, there is not really a difference. -Marten % ls -lg ~ftp/ripe/dbase/split -rw-r--r-- 1 root dbase 7301 May 12 16:46 ripe.db.aut-num.Z -rw-r--r-- 1 root dbase 1235 May 12 16:45 ripe.db.bdry-gw.Z -rw-r--r-- 1 root dbase 173800 May 12 16:46 ripe.db.domain.Z -rw-r--r-- 1 root dbase 618303 May 12 16:46 ripe.db.inetnum.Z -rw-r--r-- 1 root dbase 737450 May 12 16:45 ripe.db.person.Z -rw-r--r-- 1 root dbase 883 May 12 16:45 ripe.db.rout-pr.Z

1 0