On Tue, Aug 26, 2003 at 09:35:57AM -0400, Leo Bicknell wrote:
In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote:
If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard?
Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe.
C&W, Level3, Global Crossing and NTT/Verio are small isps? http://infopage.cary.cw.net/Routing_Registry/mainpage.html http://info.us.bb.verio.net/routing.html#VRR http://www.irr.net/docs/list.html#LEVEL3 http://www.irr.net/docs/list.html#FGC (you need to replace gctr.net with gblx.net) I'm not able to give you the skitter related metric for the "core of the internet" as i'm getting connref from http://as-rank.caida.org/cgi-bin/main.pl but please do review it and comb the rest of the list at irr.net to get an idea of how much of the internet actually is doing this and then think about if you're in the majority or the minority.
The fundamental problem with the "IRR Everywhere" notion is simple. If everyone filtered everyone, then, drum roll please:
Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide.
Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed?
Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure.
Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes "pruned" near the "edge" of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good.
If you misuse the IRR data as you state here, yeah, your network will break. Same thing will happen if you do other bad things in configuring your network policy. This is why network operations are not for those armchair geeks, you can easily cause significant unexpected problems as it relates to this.
While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve.
Yeah, but that's not what we're attempting to discuss here, we're asking what hurdles (that are not self-errected due to improper policy decisions) that honestly are preventing you from deploying irr type filtering. (or that's what I think danny was trying to ask yesterday)
In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote:
The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate
The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices?
I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics
https://stats.linx.net/cgi-pub/combined?log=combined.bits
show about 23 Gig of traffic moves through there on a daily basis.
That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined.
Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players.
Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. There are also other uses for this data. you could build max-prefix numbers off of the irr data (for example). - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.