Databases Synchronization Proposal

Laurant,

We discussed several methods to syncronise registries in the IRR
meeting in San Jose. We have talked about daily ftp's, true
syncronisation via atomic updates, maintaining diff like files as
explained last week by Daniel. I am glad that someone take this one
step further and looked at the issues in detail. However, there are
couple of important issues that were missing in your proposal.

I think the most important issue is guaranteed syncronisation at a
certain time. When you ftp the copy of x.db created at 8am from the
master registry for x.db, you know that the copy of the x.db is as
recent as 8am this morning. With the diffs, one can guarantee
syncronisation upto the time of last diff in the ftp.

I think having a guaranteed time on the syncronisation is very
important. For example, RA configures route servers using the
information received untill 2pm the previous day. With the diffs, one
can syncronise all databases to 2pm, previous day.

With what you suggest, no such guarantees are possible (or I missed
it:-). In other words how can I get a copy of ripe database at 2pm
yesterday even if the ripe database have not received all updates till
2pm yesterday because they were sent to all sorts of registries all
around the world. 

On another point, you suggest that once a week whole ftp copies of the
databases can be made to guarantee robustness for syncronisation.
Where do I get a copy of ripe.db? Ripe? In your scheme they themselves
do not have the most up to date data. The most up to data data is in
all registries plus mail queues in all sorts of places, plus mail
messages in transit between the registries. To clarify here is an
example:

7:50 am RA receives add object banana to ripe database
7:51    RA adds the object and forwards it to ripe, network is down
        and the message is queued.	
8:00 am	RA ftp's ripe's copy of ripe.db.
8:05    Ripe receives mail from RA and adds object banana

Are the databases syncronised? No. RA's copy of the ripe.db is missing
the object banana. Also RA can not tell this, as perhaps object banana
was actually deleted by sending a delete request to the registry foo.
Do you want to keep track of all these transactions? That is not a
simple job and perhaps two phase commit and true syncronisation is
simpler. 	

I think having a master registry is a good idea. A record should not
be registered anywhere if it is not registered at the master
registery. I think master registry should issue both serial numbers
and time stamps. That is records of the sort:
	database serial-number timestamp operation object	
These records can be stored for future ftp as diffs or sent around via
email (or both). Different registries can choose different options as
well. But I think, one needs diffs and a concept of master registries
to guarantee syncronisation.

My 1000 Turkish Liras:-) which is only 2 cents:-(

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California



-------- Logged at  Fri Mar 3 22:27:44 MET 1995  ---------