Filter on IXP

Mon Mar 3 09:25:18 UTC 2014

> - the IXP participants keep their IRRDB information fully up-to-date
Geez anything else but the fully up-to-date IRRDB please. That just won't fly. 
That's why I said that an up to date IRRDB would have been a nice side effect of IXP filtering. 

> - the IXP operators put in mechanisms to stop both route-leakages 
> and incorrect IRRDB as-set additions from causing things to explode. 
Yes this is a valid point

I think the technicalities of how to implement this kind of filtering at the IXP equipment is out of scope for this discussion. 

Anyways I believe IXPs should not be responsible for this mess and that BCP38 should be implemented by the participants of an IXP. 
As Saku Ytti mentioned several times Tier2 ISPs are in the best position for a successful BCP38 filtering at their network boundaries. 

adam
-----Original Message-----
From: Nick Hilliard [mailto:nick at foobar.org] 
Sent: Sunday, March 02, 2014 2:01 PM
To: Vitkovský Adam; Jérôme Nicolle; nanog at nanog.org
Subject: Re: Filter on IXP

On 02/03/2014 12:45, Vitkovský Adam wrote:
>> On the other hand, if a member provides transit, he will add its 
>> customer prefixes to RaDB / RIPEdb with appropriate route objects and 
>> the ACL will be updated accordingly. Shouldn't break there.
> 
> And that's a really nice side effect.

and it only works for leaf networks.  The moment your ixp supports larger networks, it will break things horribly.

It also assumes that:

- all your IXP members use route servers (not generally true)

- the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true)

- the IXP port ASICs can handle large L2 access lists (not generally true)

- there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain)

- there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement)

- the IXP participants keep their IRRDB information fully up-to-date (not generally true)

- the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode.

Last but not least:

- there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case)

There are many places where automated RPF makes a lot of sense.  An IXP is not one of them.

Nick