Since we are talking about NRTM, I would like to raise a question on how to filter out some objects for privacy or other reasons. 1. There are two different cases: NRTM ingress( client mirroring from server) and NRTM egress ( server mirroring into client ) 2. For NRTM egress: Usually want to filter out PERSON object for privacy. 3. For NRTM ingress: Sometime other RR may have polluted route objects or other non-standard RPSL extension. 4. Other than modified the server we can put a wrapper to filter out unwanted object then send a dummy object to the server. 5. The problem is how do you specify action ? Because you can not ADD or DEL twice the same dummy object. So the wrapper have to TRACK the action sequence. This is problematic and sometimes won't work at all. 6. The solution I am proposed is: a DUMMY action for both NRTM ingress and egress. Whenever there is a need to filter some objects, the server will send a dummy object with DUMMY action. Then the NRTM client will accept the DUMMY/dummy stream and increase the serial number without any real action. Any comment ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Andrei Robachevsky [mailto:andrei@ripe.net] Sent: Wednesday, March 06, 2002 5:40 AM To: Bjorn Danielsson Cc: db-beta@ripe.net Subject: Re: NRTM policy
Dear Bjorn Danielsson,
Bjorn Danielsson wrote:
Is anyone on this list using Near-Real-Time Mirroring to run a mirror of the RIPE database? If so, I would like to contact you to find out what procedure you went through to become accepted by RIPE as a client? (I tried asking ripe-dbm@ripe.net about this but got no sensible answer.) Please reply via private mail to me.
I am not sure what question you are referring to that got no sensible answer from the ripe-dbm@ripe.net. As far as I know the process of approving you as a NRTM client has been completed and the address you requested has been given access to the server. I also believe you received our standard "NRTM HOWTO" containing necessary information.
If you need any more assistance in this matter, please don't hesitate to contact ripe-dbm@ripe.net. In such case I would appreciate you indicate more clearly what kind of problem you experience.
Regards,
Andrei Robachevsky Database Group Manager RIPE NCC
"Lu, Ping" wrote:
Since we are talking about NRTM, I would like to raise a question on how to filter out some objects for privacy or other reasons.
[deleted]
Any comment ?
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) Only standard objects gets exported to the standard-objects DB. Then let others mirror only the instance with the standard objects. 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. 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?) regards, Arnd
Hi Ping, Lu, Ping wrote:
Since we are talking about NRTM, I would like to raise a question on how to filter out some objects for privacy or other reasons.
1. There are two different cases: NRTM ingress( client mirroring from server) and NRTM egress ( server mirroring into client )
2. For NRTM egress: Usually want to filter out PERSON object for privacy.
3. For NRTM ingress: Sometime other RR may have polluted route objects or other non-standard RPSL extension.
4. Other than modified the server we can put a wrapper to filter out unwanted object then send a dummy object to the server.
5. The problem is how do you specify action ? Because you can not ADD or DEL twice the same dummy object. So the wrapper have to TRACK the action sequence. This is problematic and sometimes won't work at all.
In fact, with both RIPEv3 and iRRd you can ADD twice (or rather many times in a row), as this is considered as an update. So in our setup we use the approach you decribed below, but with "ADD" action. We put a mirror reflector in front of all mirrored sources, and every time it sees a non-compliant object mirror reflector substitutes it with "ADD + dummy object" without losing track of serials.
6. The solution I am proposed is: a DUMMY action for both NRTM ingress and egress. Whenever there is a need to filter some objects, the server will send a dummy object with DUMMY action. Then the NRTM client will accept the DUMMY/dummy stream and increase the serial number without any real action.
Any comment ?
Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
Regards, Andrei Robachevsky RIPE NCC
participants (3)
-
Andrei Robachevsky -
Arnd Vehling -
Lu, Ping