NRTM proposal

Hi, Arnd,

comments followed.

Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net


> -----Original Message-----
> From: Arnd Vehling [mailto:av at nethead.de]
> Sent: Thursday, March 07, 2002 12:45 PM
> To: Lu, Ping
> Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta at ripe.net;
> 'db-wg at 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.