Hi Brian, at Thu, 14 Nov 1996 08:16:38 MST, you wrote:
Barring all of the obvious flames about the "if's" involved (number of data points, statistical methodology, what constitutes a violation, multiple violations, Merit stats don't mean anything, etc.) this doesn't look real good. If there are about 42000 paths in the "default-free" routing table (this part we know), and every last one of them is registered in the IRR (which isn't true), ~25% of the routes on the Internet do not jive with the IRR, according to these Merit stats.
The IRR AS origin discrepancy web page counts the number of announcements per provider that have an AS origin that differs from what is registered in the IRR. So, if two providers announce the same mis-registered prefix, this prefix will be counted twice. Though the number is still high, I suspect that percentage of incorrectly resgistered routes is much lower than 25%. We don't have numbers for the number of unique routing table entries that have IRR origin discrepancies, bit it might be useful to look at a chart of some of the larger providers. With the exception of Sprint, most providers seem to have ~10% error in their BGP announcements (of course, this is from a very small sampling). (Data from 11/18/96) Provider #RT entries #discrep % -------------------------------------------- ANS 2611 186 7.13 Advantis 183 21 11.47 BBN 8996 1129 12.55 Compuserve 1523 3 .20 MCI 15135 1578 10.43 SPRINT 14085 3584 25.45 UUNet (no information available)
Obviously, this calculation isn't exactly statistically sound, but it's something to think about. The fact that there are so many if's is kind of the point, too. If you don't trust Merit stats, whose? Is there anything else available to base any sort of conclusions on? I know of at least one example of a reported "IRR violation" that isn't, so there could certainly be (many) more. Anyone from Merit care to explain how these stats are collected, and/or if they should be considered accurate? There's nothing on the web pages concerning IRR violation statistic collection methodology so far as I can tell.
Sorry about the lack of documentation (we're working on it... :) ) The methodology is: For each entry in a RS routing table dump with an IGP origin, 1) compare the BGP aspath origin with the origin(s) returned from an exact route object lookup in the IRR. If a route object(s) exists and the origins match the BGP information, continue on and check another dump entry 2) else, find the next less specific route object in the IRR, and compare the origin(s) with the BGP aspath information. If there is not a match, flag the entry as an IRR discrepancy To address some performance/load problems, we recently began using a local, caching version of the IRR server for the discrepancy reports. Unfortunately, there are some known bugs with the new server in the way that it performs less specific lookups. So, until we get the bugs resolved, there will probably be a few errors in the discrepancy reports. Though, the bugs should result in an overestimatation (if anything) of the number of of IRR discrepancies. I agree that the quality of information in the IRR could use substantial improvements. Though, the quality of BGP information could also use improvement... To reiterate some of Cengiz's comments, I agree that real anaylsis and rational management of the Internet's topological (routing) growth requires some sort of prescriptive database. As IRR based tools and reports continue to develop and mature, I am hopeful that there will be growing incentive for ISPs to help maintain the IRR information. - Craig -- Craig Labovitz labovit@merit.edu Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785