Re: Filter update procedures

[Mike Hughes <]

On Mon, 22 May 2000, Jacques Caron wrote:

> Hi,
> 
> This is probably a recurring discussion... Feel free to point me to older 
> threads on the same subject. Also, the discussion might be more appropriate 
> in another forum (routing WG, specific IX mailing lists...)?

Yep, we have seen this one before at the LINX. At one point there was
discussion about moving "update filter" notifications to a separate list
(other than the LINX ops list), and possibly using a standard
(i.e. machine readable) format. However, that seems to have fizzled out.

> The issue is that of route filtering procedures between peers. Some of us 
> (especially those that are present on many IXes) receive quite a bunch of 
> "please update your filters with AS so and so and routes so and so", but I 
> wonder if anyone uses them? I have the feeling most people either:
> - don't filter anything
> - filter based on IRR (RADB/RIPE DB...) contents (using an as-macro), with 
> regular automatic updates

More common, certainly from personal experience, is the setting of
maximum-prefix on your peering sessions. 

This tends to protect against people sending you the "boat load", while
allowing for the smaller changes in announcements you would get from a
"Please update filters" type of email.

Of course, you need to tune this on a per-peer basis to make sure it works
properly (for example, some networks offer 4000+ prefixes over peering,
and others only 1), and keep an eye if they start transiting a largish AS,
which could push them over the limit.

> Some specific field in AS descriptions in the RIPE DB to indicate 
> notification of changes would be great too. It would avoid "spamming" 
> everybody with the filter updates.

OK, hypothetically, let's call this field "update-c", and make it an
optional field in autnums. This would also rely on people to do the right
thing and only email update-c addresses, and not to "fallback" on spamming
the tech-c and admin-c. There's a possibility that people's "update
peering" robots could be set of fall back on other contacts in the
object. Maybe it will work?

Mike
-- 
Mike Hughes	Senior Network Engineer	London Internet Exchange
mike@localhost	http://www.linx.net/	
     "Only one thing in life is certain: init is Process #1"