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.