|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Why does Sprint have address filters again?
At 08:40 AM 6/1/98 -0700, Roeland M.J. Meyer wrote: >I agreed to the stipulation, in advance so I wouldn't get lecture #101, yet >again. The issue here is that ASN's get around prefix filtering, to my >understanding. If everyone had an ASN then we'd be right back to they >problem that started prefix filtering in the first place, ever growing, and >humongous, router tables. Legacy routers have problems with this. *sigh* I will never understand this. I have ... 'conversed' with Sean and others at length about this. Unfortunately, I wasn't running a router with a full table at the time, so I just don't get it. Sprint claims to have this policy for the "good of the Internet". I find this part particularly interesting: <Quote from http://www.sprint.net/filter.htm> In support of slowing the growth rate of route advertisement within the Internet, SprintLink filters prefixes from non-customer BGP neighbors longer than 19 bits in the 206.0.0.0/8 and 207.0.0.0/8 block to the end of the current range of class C addresses. </Quote> I am really puzzled about this. Based upon the evidence Sean Doran presented on another list, I did not see any effect on the table from 112. Specifically, looking at http://www.telstra.net/ops/bgptable.html (part of said evidence), I see faster growth post-112 than pre-112. This increase is immediately apparent after 112's inception, so it's not a "long term" problem. I am pretty sure this is not a direct result of 112, but I think it shows that 112 did not have its intended effect. So, I guess things were going on of which I am completely unaware, and which do not show up on the graph. As I said, my problem is I just do not see the problems everyone is complaining about in the data. Perhaps others who presumably know more about this than I please comment? There are a couple things I am sure of. I am sure Sprint has fewer routes in their table than other backbones because of 112. One could argue that this gives Sprint less, or at least less optimal, connectivity than other large backbones. Add the fact that Sprint has not been significantly more stable than other backbones (there have been accounts on this list of the opposite in fact, but I am not a Sprint customer, so I have no first hand knowledge). One is left wondering why one should use Sprint for transit at all? One could also argue that 112 has helped shape the allocation policies of ARIN and other registries, and one would probably be correct. I personally feel using one company, even one as large as Sprint, to define global allocations policies is a Bad Thing. Of course, there's nothing I can do about it anymore. That is a completely separate topic anyway. It has been proposed that Sprint's peers filter Sprint with a 112-link filter, but use their default filters on all other peer/transit connections. I would like to see what Sprint's peers have to say about the possibility of filtering Sprint announcements - and Sprint alone - the same way Sprint filters their peers. Sean Donelan at DRA claims he does this, does anyone else? Customers and non-peers are also invited to comment. I personally think this would be an outstanding idea, but I have not looked at all the things it would break. Of course, if one is to believe Sprint, it should break nothing. Or at least nothing that shouldn't be fixed. ;) This is especially relevant considering Sean's comments in September of 1995 (while working for Sprint) on this list. Specifically: "...at some point we certainly will begin stopping the announcement of this type of long prefix [longer than /19] to our external peers...". It's been almost 3 years, one is left to believe that Sprint will never actually do this. To his credit, Sean also publicly encouraged all Sprint's peers to filter Sprint. So at least we know Sean believes in filtering 100%. But does Sprint? Or will the hypocrisy continue? >Roeland M.J. Meyer, ISOC (InterNIC RM993) TTFN, patrick ************************************************************** Patrick W. Gilmore voice: +1-650-482-2840 Director of Operations, CCIE #2983 fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tomorrow's Performance.... Today" **************************************************************
|