I believed we are talking about two different things: In your scenario: Your client has a different serial number than RIPE's one. let's say it goes like this, RIPE:123 YOURS:111 RIPE:124 YOURS:111 (filter out) RIPE:125 YOURS:112 RIPE:126 YOURS:112 (filter out) RIPE:127 YOURS:112 (filter out) RIPE:128 YOURS:113 RIPE:129(for some reason it is lost) YOURS:113 RIPE:130 YOURS:113 (filter out) RIPE:131 YOURS:114 How can you tell there is something missing ? Also next time the client restart which serial number is it going to use ? Our scenario: The client maintain the same serial number as RIPE's. RIPE:123 OURS:123 RIPE:124 OURS:124 (dummy update) RIPE:125 OURS:125 RIPE:126 OURS:126 (dummy update) RIPE:127 OURS:127 (dummy update) RIPE:128 OURS:128 RIPE:129(for some reason it is lost) OURS:128 (client detect mismatch stop here) I want to stop discussion about different scenarios and just limit this to the current NRTM practice: NRTM server and client maintain the same serial numbers. Best Regards. 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: Tuesday, March 12, 2002 10:35 AM To: Lu, Ping Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta@ripe.net; 'db-wg@ripe.net'; Dieken, Chris; Beaumont, Dave; Resh, Stephanie; Phil Syskes Subject: Re: NRTM proposal
"Lu, Ping" wrote:
To be more precise. The data is up to date if the highest serial number on the mirror server matches the highest serial number on
me wrote.. the client.
Exactly. That's why the client can't just ignore any private object. It will need to do a dummy update to advance the serial numbers.
Nope. The only thing which the client really needs to know is the highest serial number _he_, the client, did process.
If the highest serial number internal to the datastructure of the client matches the one of the mirror source is of no concern.
Please keep in mind that i can write a mirror client which doesnt needs to have the same structure as the ripe-db and therefore may very well miss a "serial" number like the ripe-server has.
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
Hi, "Lu, Ping" wrote:
I believed we are talking about two different things:
Yupp. We are not doing direct mirroring at the moment as we are not allowed to put out CW-Europes allocation into a own registry and get this mirrored by RIPE.
In your scenario: Your client has a different serial number than RIPE's one. let's say it goes like this, RIPE:123 YOURS:111 RIPE:124 YOURS:111 (filter out) RIPE:125 YOURS:112 RIPE:126 YOURS:112 (filter out) RIPE:127 YOURS:112 (filter out) RIPE:128 YOURS:113 RIPE:129(for some reason it is lost) YOURS:113 RIPE:130 YOURS:113 (filter out) RIPE:131 YOURS:114
How can you tell there is something missing ?
You can only tell by comparing the objects.
Also next time the client restart which serial number is it going to use ?
The client saves the last _processed_ serial number and goes on from there. Thats the way our e-mail synchronisation with the ripe works at the moment as we are not able to mirror at the moment due to several reasons. [..] One could log the serials of the dropped objects and count them, for example.
I want to stop discussion about different scenarios and just limit this to the current
ack
NRTM practice: NRTM server and client maintain the same serial numbers.
No, thats RIPE-Software practice. The client only requests a serial-range and the server sends this range. Obviously that practice has some constrains when it comes to privat objetcs. Exchanging privat objects is obviously out of the scope of this protocol. And object/attribute filtering on client is IMO bad too. Due to this reason i opt for the following setup: [Privat Registry] -> syncs with -> [official mirror server] <-> [mirror client] Whereas: [Privat Registry] (CWs) internal registry with privat objects [Official mirror server] (CWs) Server containing only standard RPSL objects of the registry [mirror client] RIPE, RADB etc. That way all the privat objects stay private. In addition its not possible to query them externally, and only standard RPSL objects are exchanged with external mirrors. Another option is to enhance the NRTM protocol or start developing distributed registries. BTW.: Filtering private attributes and classes (objects) out of an object stream is easy to accomplish. regards, Arnd
Hello, some notes on what i called "sync" in the last e-mail: Synchronisation from the privat-db to a mirror-server can work like this: Step-1: Script connects to db with private objects via NRTM and gets a list of objects updates. Step-2: Script filters private objects and attributes and replaces the "SOURCE:" value. Step-3: The new Object-Stream is uploaded to the mirror-server (not the client, like RIPE) either using e-mail (we are using this for updating RIPE) or using the "dbupdate" utility directly. 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