RE: No one behind the wheel at WorldCom
See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it. I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Sat 7/13/2002 10:20 PM To: Frank Scalzo Cc: Stephen Stuart; nanog@merit.edu; Paul Schultz Subject: Re: No one behind the wheel at WorldCom On Sat, Jul 13, 2002 at 09:21:16PM -0400, Frank Scalzo wrote:
The underlying problem, is that there are no good widely deployed solutions for controlling what the large backbones inject into the routing table at peering points. A large tier 1 deaggregates towards another bad things happen. It would be nice if there was a supportable way to only allow one isp to advertise appropriate routes to another. The IRR stuff is a neat idea but I dont think many ISPs trust it enough to use it to build ACLs.
If everyone maintained current IRR entries, it would work just fine. The real problem is there are still a lot of networks who's idea of filtering their customers is a prefix-limit or a filter you have to call or email in manually. The only people who actually maintain accurate IRR entries (other than the occational net kook) are those whose transit depends on it. Trying to convert an existing customer base to IRR is a nightmarish task, some of these large established providers will probably NEVER do it unless there is some actual motivation. Supposidly Level 3 requires IRR filtering on their peers, but do they actually try to enforce this? I know they do an excellent job maintaining their own IRR entries, but I'm certain they peer with people who don't have a current db. Probably not, since the vast majority of their current peers don't meet their current peering requirements. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote:
See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it.
[CC: list trimmed] Actually, I think you'll find that bad data is only a small part of the problem; even with good data, there isn't enough support from various router vendors to make it worthwhile; it's effectively impossible to prefix filter a large peer due to router software restrictions. We need support for very large (256k+ to be safe) prefix filters, and the routing process performance to actually handle a prefix list this large, and not just one list, but many. IRR support for automagically building these prefix lists would be a real plus too. Building and then pushing out filters on another machine can be quite time consuming, especially for a large network.
I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6.
This still doesn't solve the scaling issue. This is no different than running your own RR, which many ISPs already do -- and they still have to exempt many of their peers. Typically, RR derived prefix filtering is something reserved for only their transit customers. If it were that easy, everyone (well, some people) would be doing it. --msa
There are different types of filter tho and I'd suggest they are suitable in different circumstances. eg small peer < 100 prefixes - build prefix filter list, as path list middle peer - either depending on requirement (eg cust, peer) large peer > 1000 prefixes - as path filter plus max prefix I'm not implementing the above so the numbers and suggestions are a little arbitrary but I'm making the point that you can filter smaller peers who are less experienced and more likely to give an error and for larger peers you have to be less granular but can still impose failsafes without increasing CPU. Steve On Mon, 15 Jul 2002, Majdi S. Abbas wrote:
On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote:
See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it.
[CC: list trimmed]
Actually, I think you'll find that bad data is only a small part of the problem; even with good data, there isn't enough support from various router vendors to make it worthwhile; it's effectively impossible to prefix filter a large peer due to router software restrictions. We need support for very large (256k+ to be safe) prefix filters, and the routing process performance to actually handle a prefix list this large, and not just one list, but many.
IRR support for automagically building these prefix lists would be a real plus too. Building and then pushing out filters on another machine can be quite time consuming, especially for a large network.
I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6.
This still doesn't solve the scaling issue. This is no different than running your own RR, which many ISPs already do -- and they still have to exempt many of their peers. Typically, RR derived prefix filtering is something reserved for only their transit customers.
If it were that easy, everyone (well, some people) would be doing it.
--msa
On Mon, Jul 15, 2002 at 01:39:01PM +0100, Stephen J. Wilcox wrote:
eg small peer < 100 prefixes - build prefix filter list, as path list
maxprefix makes sense here too on a Juniper router since it applies maxprefix to the _received routes_ (not to the routes after filtering as Cisco does it). tschuess Stefan -- Stefan Mink Schlund + Partner AG Tel: +49 721 91374 0 Netzwerkabteilung AS8560 Fax: +49 721 91374 212 Key fingerprint = 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA
participants (4)
-
Frank Scalzo -
Majdi S. Abbas -
Stefan Mink -
Stephen J. Wilcox