Databases Synchronization Proposal

	FYI
-------------------------------------------------------------------------------
	Proposal for a Simple Database Synchronization Model
	lpj. 03-02-95. Version 0.1


Object of this memo.

	Dissemination of the same data among Routing Registries Databases
has raised the problem of the distribution and synchronization of the
data in the different registries. Either Inter Registry propagation or
intra registries copy (for backup purpose) is still an open problem. Right
now synchronization of databases is done by daily FTP transfer of the whole
database between registries. Database are synchronized only once a day
(Desynchronization Delay of less than 24 hours).

	The current implementation of the Routing Registries Databases is
based on e-mail updates ('RIPE database model') sent to one registry. The
present proposal describes a way to synchronize databases based on mail
forwarding aimed to keep the desynchronization delay less than a few minutes.

Model

	In the current scheme the user mails an update to the registry
(the registry is known by its e-mail address). The mail is processed,
a report is sent back to the user and eventually the data is registered
into the database.

(user)  -- [e-mail] --> {Registry A Incoming Processing :: Database}
       <-- [Report] --
				|
			       FTP
				|
				V
			{Registry B :: Database}

	Within the proposed model the incoming Processing entity will
forward a copy of the mail to the registry B's incoming Processing
entity.  In order to prevent a new report to be sent to the user by the
registry B's process, the sender of the mail will be set to a special
generic address ("dbadmin at Registry_A") which will be recognized by the
registry B and won't generate a report to the sender.

(user)  -- [e-mail] --> {Registry A Incoming Processing :: Database}
       <-- [Report] --
					|
			   [e-mail/from = dbadmin at Registry_A]
					|
					V
		         {Registry B Incoming Processing :: Database}

	The desynchronization delay is set to the mail forwarding time
(less than a few minutes). The model is perfectly symmetric: the user
can send the request to the registry B which will forward it to the
registry A.

(user)  -- [e-mail] --> {Registry A Incoming Processing :: Database}
       <-- [Report] --
					     ^
                                        |    |
                           [e-mail/from = dbadmin at Registry_A/B]
                                        |    |
                                        V 
       <-- [Report] --
(user)  -- [e-mail] --> {Registry B Incoming Processing :: Database}


Protocol

	Every registry keeps a list of neighbor registries to which forward
a copy of every incoming mail.

	When receiving a mail the process checks if the sender is
one of his neighbor registries. If so the report generation is turn off
(this can be implemented by replacing the from address by /dev/null
before passing the mail to the database processor -- dbupdate).
	The process creates a new header field which will contains all
the registries name through where the mail was forwarded. The filed will
look like:
	X-dbpath: dbadmin at Registry_A

	If this field already exists the process just adds its name to the
list:
	X-dbpath: dbadmin at Registry_A, dbadmin at Registry_B

	The process forwards a copy of the mail to all neighbor registries
which are not listed in the 'X-dbpath' field. By doing that the process
prevents any loop in the registries configuration. The process also
replaces the from/reply-to address by its own.

	Another email header field can be added too: if the X-dbtrace field
exist then a report is sent to the user listed in the 'reply-to' field.
This allow debugging of the path followed by a given mail by analyzing
the from line and X-dbpath line of all report sent by the registries
receiving the mail. It also gives the user a map off the topology of
the registries.

	The model supposes that the database updates are time stamped and
the database administrator can discart any out of date (older than the
current last update time) request.

Discussion

	If one of the registry is down, e-mail to that registry will
be queued and resent when the registry is up again. This mechanism is
inherent the the e-mail service. The dead registry will be resynchronized
when coming up again.

	Loop are detected with the use of the X-dbpath field.

	User can send email to any registry with the assurance all
registries will get updated.

	In case of intra registry backups (2 or more databases running
for the same registry), the use of several MX record allows the
administrator to split the load of the incoming mail between the
databases backups. Moreover if one host is down the mailer can choose to
send the mail to an alternative MX server.

	The model is completely symmetric, no database is privileged.

	A FTP transfer of the databases between registry once a week is
still a safe way to resynchronize the databases in case of failure of the
mail forwarding. During the FTP transfer e-mail update should be disabled.

	The present model does not deal with database queries (whois
requests).

--
Laurent Joncheray,                                  E-Mail: lpj at merit.edu
    Merit Network Inc, 4251 Plymouth Rd, Suite C,   Phone:  +1 (313) 936 2065
    Ann Arbor, MI 48105, USA                        Fax:    +1 (313) 747 3185
"This is the end, Beautiful friend. This is the end, My only friend, the end" JM



-------- Logged at  Thu Mar 2 19:48:32 MET 1995  ---------