NRTM proposal

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 at cw.net
> 
> 

Regards,


Andrei Robachevsky
RIPE NCC