Verio Peering Question

Sat Sep 29 18:58:09 UTC 2001

On 29 Sep 2001, Paul Vixie wrote:

> there has to be a limit.

A limit is needed, but the filtering method in question to me essentially
says this:

if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat
as much as you want.. we feel this is an acceptable practice.

Yet, if you're a legitimately multihomed customer wants to push out a
single /24 (1 AS, 1 prefix) that is not considered acceptable.

The only kind of prefix filtering I would want to implement is something
that can accomplish:

1. Define threshold, say /20 or /18 or hell even /8.
3. all prefixes longer than threshold get held until entire tables are
loaded
3. start looking at the longer prefixes across the entire ipv4 space
starting with the longest and finishing at threshold+1
4. if prefixes longer than threshold appear as part of a larger aggregate
block that *originate* from the same AS, drop.
5. if prefixes longer than threshold originate from a different AS than
the aggregate, accept.

This way I could get rid of redundant information yet at the same time not
cause any trouble to smaller multihomed customers.  I'm not saying that we
should allow /32's to be pushed everywhere either.  As you said there has
to be a limit, and /24 seems to be a pretty good one if something along
the lines of the above mentioned filtering algorithm could be used.

I'm sure in reality there's many reasons this would not be able to be
implemented (CPU load perhaps) but it would atleast do something more than
a "gross hack" that nails some offenders, not all by any means, and
impacts multihomed customers who are only a portion of the problem that
the current prefix filtering solution does not solve.

paul