Hi, Arnd, comments followed. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Arnd Vehling [mailto:av@nethead.de] Sent: Thursday, March 07, 2002 12:45 PM To: Lu, Ping Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta@ripe.net; 'db-wg@ripe.net' Subject: Re: NRTM proposal
[snip]
How about setting up an instance for private objects and one with standard-objetcs. Let the one with the private objects synchronize with the standard one (i.e. per e-mail-script)
As far as RIPE-DB vs. IRRD, RIPE-DB implements IRT object (considered private) but IRRD doesn't. There is always a situation where the standard one need to synchronize with the one with private objects but need to filter out private objects (like RADB mirror from RIPE ). Then internally RIPE NCC will need to mirror the data with IRT to keep the data integrity.
Only standard objects gets exported to the standard-objects DB. Then let others mirror only the instance with the standard objects.
The problem is the serial number will increase when you update a private object then when other mirrors get only the standard object the serial number mismatched each other. As regarding to the PERSON object, this is a situation for STANDARD mirroring STANDARD but needs to filter it out also.
This has also the advantage you dont mix ip-management only data with routing-registry relevant data. As you might know Cable&Wireless Europe has modified version of the RIPE-DB running which contains only IP-Management data but no route objetcs etc.
We choose RIPE-DB software because it does both together while ARIN region use two different databases for Route and IP-Management. And it is a disadvantage for us constantly trying to merge both data together. One thing is RIPE-DB cross-checking between the inetnum object (IP-Management) and the route (routing) object makes it very consistent for the RIPE region. And I considered that an advantage rather than a disadvantage. PS. CW Europe is on a different AS number now but it will merge into AS3561 eventually.
This isnt an ideal solution but it works. The right solution would be to establish distributed route registries and not to mirror each other.
There is already a RFC out which describes how distributed registries could work but i cant find it at the moment, sorry. (Anyone know which RFC it is?)
Even for a distributed system (like DNS) there is a need for caching (mirrored data) and you still have to put them together at some point.
Hello, about the NRTM problem. NRTM works by requesting objects by specifying a range of serials numbers. The NRTM client usually requests from the last processed serial number upwards until he reaches the maximum serial number available in the source server. (See the RIPE-DB doc for explanation) But all the NRTM client gets (and the server sends) is a (ASCII) stream of objects with the appropriate action to take (add / delete). If receiving a stream with objects considered "non-standard", or private, all the nrtm client (or the server) has to do is to filter out objects (and maybe attributes) which are considered of private nature. The client doesnt need to know anything about which serial number relates to which object. (i.e. The serial-numbers must not be in sync between a source server and the mirror) This can easily be accomplished by creating a perl script which filters the NRTM ascii stream. Actually we are using such a script for synchronizing our local ip-management ripe-database with the RIPE amsterdam. Could you therefore please elaborate on where you are seeing a problem with the serial-numbers while mirroring? best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av@nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212
participants (2)
-
Arnd Vehling -
Lu, Ping