Who uses RADB/IRR?

briand at spare.de.teleglobe.net briand at spare.de.teleglobe.net
Mon Jan 25 23:29:58 UTC 1999

> DA> I started looking at the RADB, but haven't got ourselves setup yet.  Does
> DA> anyone actually deny routes which aren't listed in the RADB?  I guess what
> DA> I'm really asking is how important is it to be in the RADB? Does it get
> DA> more important sometime soon?

Yes, for peers and customers. Pretty important, at least for international
connectivity (which is what we provide). Yes. (See below.)

> "Important" is hard to define.  People tend to register in the RRs and make
> use of the RSes because:
> [1] It's the right thing to do to publish public policy.  It's like
>     signalling before changing lanes.
> [2] It makes life easier on yourself and the community that participates in
>     configuring off the RRs.

[3] One word says it all: scaling.

The use of the RADB to register routes and routing policy, permits the
automated generation of all types of ACLs, independent of the size of
the ACL. Manual methods do *not* scale, and while authentication of the
contents of the RADB are questionable, this is addressable and only requires
more people to update their maintainer objects (to use more-secure methods).

Here is the crux of the argument why anyone would *require* their peers
to register:
    - if you filter your customers by hand, your filters are suspect
    - if you filter your customers by RADB, not so much
    - if you don't use the RADB for customer filters, I'm not comfortable
	trusting your routes blindly, and want to filter you
    - if you don't filter at all, I *insist* that I filter you
    - I don't want to build a filter for you, which is orders of magnitude
	bigger that your filters for your customers, by hand
    - thus, I want you to use the RADB
    - but, if you use the RADB, you can automate your customer filters!

    So, if you use the RADB to build your customers' filters, I *could*
    consider trusting you, but at that point it is trivial for me to
    build a filter for you. If you don't, I can't trust you, and can't
    easily filter, so I won't peer with you. (!!)

Teleglobe (ie, us) use the RADB for building ACLs for *all* customers
and peers. (Well, obviously not for statically-routed customers, but
those are registered from our AS.)

If someone doesn't register or maintain their as-macro, for example,
we maintain our own IRR, irr.teleglobe.net, and make a private "snap-shot"
of this peer's set of AS's, and build a proxy as-macro, which is immediately
out-of-date, but is updated periodically, and is a heck of a lot better
than running unfiltered. This is the only thing we do that even vaguely
resembles manual support for non-registrants.

We require that route objects themselves be registered, regardless,
in order to accept routing updates. We have no interest in attempting
to keep the whole internet proxy-registered on a per-route-object basis!

While we currently maintain at least one transit relationship, this will
still permit connectivity to be established via such transit providers;
once we switch to pure-peering for connectivity, this registration *will*
be very important if you want to access any of our customers.

We currently represent approximately 15% of the reachable Internet,
and our growth rate is greater than that of the general industry,
ie. expect this percentage to increase.

We don't want to force our policy on anyone else, but we insist on
not being forced by others into changing our policy. Our policy is
to filter. Our filters use the RADB. Anyone who wants to peer with
us, either at NAPs or via private link, must register. If they don't
keep the RADB up-to-date, they will at some point announce routes
that we filter out. This is their problem, not ours.

If anyone wants to register but is concerned about public visibility,
an option is to run a private IRR, and permit your BGP peers to query
this IRR. However, if you provide transit to anyone, they would need
to be registered on either your IRR or a public IRR, and if you get
transit from someone, their peers will need access to your info as well.
These all point in the direction of public IRR's as the right way to go.

> DA> I would also tend to think [based on limited BGP knowledge] that it would
> DA> only be a problem if your direct upstream used the RADB or if your upstream
> DA> is RADB filtered by their peers. Is this true? 

Or if *their* upstream is filtered by peers, etc, etc, up to the "tier 1"
providers. Of the big tier 1's, I believe Sprint is the only non-registrant
of significance (ie numbers of routes in double-digit percent of global table.)
If this ever changes, then global reachability could require registration,

> You forgot the word "exclusive".  Many providers in addition to configuring
> off the RR also manually configure in (by hand) those who do not have
> registered policy in the RRs.  I consider this suboptimal administrative
> practice but you do what you have to.

Refusing to manually update non-registered networks, is a significant
lever to "encourage" the other guy to register. If enough people join
this effort, *everybody* wins.

Be advised, however, that filtering *big* networks takes lots of space
in your router configs, and even with "service compress-config", you
can hit the wall pretty easily, and eventually need to save configs
onto flash or a local TFTP server (and don't forget to change boot
buffersize!). However, this is no reason not to filter, it is simply
a change in procedure needed while Cisco ships pitifully small NVRAM
on their core router products. ;-)

> And for those who only do
> aspath-based filtering... keep knocking on wood. |8^)

For those who do not grasp the subtlety of this last statement:

More than once, in recent memory, has a clueless small ISP done the
unthinkable of redistributing BGP into an IGP, and back into BGP, thus
appearing to announce the entire Internet from their own AS. Allowing
these routes without filtering, resulted in major blackholing/meltdown
of big pieces of the Internet, notably those ISPs providing transit
to the small ISP and its ISP without filtering.

Those who do not learn from history are doomed to repeat it.
Those who do not learn from history are doomed to repeat it.
Those who do not learn from history are doomed to repeat it.

In case anyone is concerned about operational impact of filtering:
The filtering we discuss here is filtering routing updates, not filtering
of packets. Routing updates generally represent a negligible load, and
filtering is inexpensive in this regard. The only times where routing
updates are a big load, is the *precise* time when you really want to
be filtering out the updates, eg the redistribution situation above.

Brian Dickson

More information about the NANOG mailing list