North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Verio Peering Question

  • From: Paul Vixie
  • Date: Sat Sep 29 11:48:50 2001

> Can someone who is in favor of implementing filters explain to me why
> slicing a /16 into 16 /20's is any different than slicing a /20 into 16
> /24's?

with the understanding that i'm explaining why MIBH did it rather than
explaining why you should do it (if indeed you should, which is not even
a conversation i could find myself in), the reasoning is/was as follows.

there has to be a limit.

that's all.  that's the full extent of the reasoning.  some limit has to
be chosen, because without limits, human nature kicks in and "the people"
start voting themselves bread and circuses.  i'm not interested in going
down that path because it's a recipe for _finding_ the limits of the
global routing system, both in table size and in delta volume.  (we'd find
it when the 200,000th /32 was injected, and by that time it would be hard
to reverse course.)

so there's going to be a limit.  the number of routes allowed into a router
shall be non-infinite.  that limit can be selenforced in a number of ways:

	1. total number of routes
	2. total number of routes per peer
	3. prefix length

now, #1 would just be too unpredictable.  which routes were present would
depend on what order the peers came up.  so, one day, some routes, the next
day, some different routes.

#2 is in fact in wide use, but as an error ceiling to keep a peer from 
accidentally sending you a full table rather than as a way to apportion
a router's resources.  in a world which (clearly!) wants me to store 200,000
/32's, though, it's difficult to imagine how #2 helps prevent this.

#3 is a gross hack which happens to have the nice properties of "predictable"
(one day's routes will be much like another day's routes) and "minimal impact"
(the long prefixes i'm throwing away almost always have shorter "covering"
routes).  and, #3 is negotiable per peer.  abovenet allows its peers to send
long prefixes because this makes "longest exit" possible.  (this might or might
not cause abovenet some scalability problems, but it's their decision and will
impact noone except them and their customers.)

some of you know that i had some involvement in both MIBH and abovenet and
may be thinking of asking why these networks had different prefix filtering
policies.  two answers: MIBH wasn't a global network so "longest exit" wasn't
going to be possible in any case; and MIBH didn't own any GSR's.

> If the thought is "you're given a /20, i only want to see a /20.." then
> why doesn't "you're given a /18, I only want to see a /18" also apply?

because there's got to be some limit.  if you want to set that limit at
"you were given a /24 so i don't want to see any /28's from you", then fine.
but obviously some trial and error has gone on here, and the folks who have
prefix filters have set them so that (a) any longer and there'd be too many
routes, and (b) any shorter and there'd be too much nonreachability.  this
is one of nature's equilibriums.  it has shifted back and forth over time.
the filter lengths verio is using are obviously in verio's best interests or
they would have different ones.

> I don't have any hard evidence to know how much of an impact this
> actually has, but I would be very interested to see how many more specific
> /19's and /20's exist in a "verio-filtered" table that were allocated as
> /16's and shorter.

i'm pretty sure verio has a looking-glass instance, so you can find out.