-----Original Message----- From: Andrei Robachevsky [mailto:andrei@ripe.net] Sent: Monday, March 11, 2002 11:00 AM To: Lu, Ping Cc: Bjorn Danielsson; db-beta@ripe.net; 'db-wg@ripe.net' Subject: Re: NRTM proposal
Hi Ping,
[snip]
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.
That sounds resaonable. If the client side wrapper see a [ADD|UPD|DEL]/unknown_object action then it should translate it to ADD/dummy_object and send it to the database. Should we consider this as the standard way to filter out object or a work-around ? Also can we all agree on a standard dummy_object like "limerick" (no side effect) ? [snip again] Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
That sounds resaonable.
If the client side wrapper see a [ADD|UPD|DEL]/unknown_object action
Theres only an ADD and DEL action, no Update. Update = ADD
then it should translate it to ADD/dummy_object and send it to the database.
If it sees an unkown object/or attribute it should IMO discard it. On the other side i would opt for server (mirror) side filtering if the mirror has non-standard objects. The client should only reveive RPSL objects and put dummys in where needed. Like person objects when mirroring RADB. All private objects should be filtered before reaching an mirror client. 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