RE: Filter on IXP

[Vitkovský Adam <adam.vitkovsky () swan sk>]

> - 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 () foobar org] 
Sent: Sunday, March 02, 2014 2:01 PM
To: Vitkovský Adam; Jérôme Nicolle; nanog () 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