IRR

Ok, this is in follow up to a discussion Bill Woodcock, John Hawkinson,
Kim Claffy and I had on the IPNMoo (or CAIDAnce or whatever it's called)
regarding the IRR. This discussion led me to ask a bunch of questions. I'd
like to present these questions for discussion, and share a few of my
comments.

How accurately does the IRR represent the actual routing policy of the
various participating networks and of the Internet as a whole?

Well, according to the IRR Violations statistics at
http://compute.merit.edu/problems.html, not very well.

Since MAE-East is the "most important" (don't even start on that one)
exchange on the Internet, let's look at the very few datapoints available.

10187 IRR violations at MAE-East on 11/13/96
9873 IRR violations at MAE-East on 11/12/96

There is no data available on the web page for any other days.

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.

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.

To quote the eloquent folks at Merit:

"Maintaining accurate IRR information is important as several providers
base their router configurations on IRR information. Incorrect IRR data
may result in loss of connectivity.

The IRR also provides a valuable source of information for analysis and
debugging tools."

How many providers are basing their policy solely on IRR information? Are
these providers (if they exist) at all concerned with the notion that (if
the RA statistics on IRR violations are at all useful) they may not be
able to get to up to 25% of the Internet at any one time? Might the IRR be
more harmful than goodful if it's actually used to generate router
config's by any small group of providers, and not by everyone? (Unless you
think segmentation is good). Is the IRR more valuable as a "source of
information for analysis and debugging tools" than as a source of
information to base routing policy on? I would say apparently so. Is the
IRR supported? Well, as far as I can tell almost everyone that should be
participating (in some form) is. Is it supported in the sense that
everyone that is participating is commited to maintaining accurate
information? I would say apparently not. Is it supported in the sense that
it is actually used for anything other than "analysis and debugging"? (And
what sort of useful analysis can be done with data that is 25% bad
anyhow?) I don't know. Should the IRR be used for anything presumed to be
"actually useful"? Well, I certainly wouldn't rely (solely) upon it. How
about you? If the IRR were useless would it break the Internet? Nope.
Could the IRR improve the Internet if it were used by everyone? Maybe.
Should the IRR exist? I think yes.

This whole "discussion" begs a lot of other questions. Adressing them is
"beyond the scope of this document". :slight_smile:

To be Scott Bradner for a moment, here's a disclaimer.

I don't have large sums of grant money to do statistics, and I have to
rely on people who do, so don't complain about how terrible my stat is. I
know many (all?) of these questions have been brought up before. I believe
there is interest in discussion, and so I have brought them up again. If
you don't want to talk about it, don't. These bits will not break your
network (well, unless you're <insert anyones favorite congested network

).

Brian

I build the router configuration tool that most providers use. I also
build quite a few analysis and diagnosis tools using IRR. I will
respond to this message from that perspective of a tool builder.

Brian Merritt (bmerritt@asdf.getnet.com) on November 14:

How many providers are basing their policy solely on IRR information? Are
these providers (if they exist) at all concerned with the notion that (if
the RA statistics on IRR violations are at all useful) they may not be
able to get to up to 25% of the Internet at any one time? Might the IRR be
more harmful than goodful if it's actually used to generate router
config's by any small group of providers, and not by everyone? (Unless you
think segmentation is good). Is the IRR more valuable as a "source of
information for analysis and debugging tools" than as a source of
information to base routing policy on? I would say apparently so. Is the
IRR supported? Well, as far as I can tell almost everyone that should be
participating (in some form) is. Is it supported in the sense that
everyone that is participating is commited to maintaining accurate
information? I would say apparently not. Is it supported in the sense that
it is actually used for anything other than "analysis and debugging"? (And
what sort of useful analysis can be done with data that is 25% bad
anyhow?) I don't know. Should the IRR be used for anything presumed to be
"actually useful"? Well, I certainly wouldn't rely (solely) upon it. How
about you? If the IRR were useless would it break the Internet? Nope.
Could the IRR improve the Internet if it were used by everyone? Maybe.
Should the IRR exist? I think yes.

There are quite a few providers who are using RtConfig to configure
their routers. There are providers who have their own configuration
tools as well. So far, everyone who has given me feedback on using
RtConfig to configure their production routers have been positive and
enthusiastic about it. They find it to be a lot simpler/more manageable
to specify policies at the high level and generate low level router
configurations from it than configuring each router individually and
maintaining consistency across them.

The data needed for these providers are all accurate. An in some case
the data become even more accurate after they started using the tools.

Is the data 100% accurate? No. Would it help if it were?
Definitely. We have written a tool to analyze the policies and the
Internet topology in IRR and aggressively suggest CIDR aggregations
which do not break routing. This tool is an important one, because
Internet is growing, the topology is becoming more complex, and more
and more fraction of the engineers are not up to speed on cidrization.
However, this tool needs close to 100% accurate policies to work
effectively. Otherwise, the routing may break (with small probability
since the tool is very pessimistic when the policies are missing).

Recently, we focused on tools to make IRR more accurate. We built roe,
route object editor. A provider by feeding a routing table dump, can
fix most of its incorrect route objects by few mouse clicks. aoe,
autonomous system object editor, will be released soon which tries to
do the same for the aut-num objects.

My few Liras.

Cengiz

In article <hot.mailing-lists.nanog-199611181859.NAA09628@merit.edu>,

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).

Sprint install folks have this tendancy to put in static routes regardless
of whether you're peering or not. At least that's been my experience
getting multi-line setups installed.

I'm only half-kidding when I suggest telling a sprint installer "yeah
we have our own IPs, 172.16/16". If you do end up peering then they
seem to put a static in for the class C that contains your loopback
interface. You can get them to change it, but the default seems to
be static-everything.

Do any providers reserve ips for use on loopbacks? i.e. nets they
divide into /32s to point at loopbacks on the customer router. This
would seem to be a prudent measure for many multihomed customers --
I'm loathe to use any PI addresses for loopback-peering because of
the potential for mistakes with static routes to the loopback address.

Dean