IRR

Craig Labovitz labovit at merit.edu
Mon Nov 18 18:59:45 UTC 1996


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 at merit.edu
Merit Network, Inc.			(313) 764-0252 (office) 
4251 Plymouth  Road, Suite C.		(313) 747-3745 (fax)
Ann Arbor, MI 48105-2785







More information about the NANOG mailing list