|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Verio Peering Question
> 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.
|