How about just doing like all other ISPs do? I.e.
do policy at as-path level w/o the benefit of RADB.
You don't need any new software to do that, and
can do that right tomorrow.
As it is now the ANS's policy to use RADB data to filter
incoming routing updates generates about 60% of our
trouble tickets, which is particularly aggravated by
the fact that in most cases the resolution is completely
outside of our control (like in case of AS 1800).
IMO RADB already created more troubles than it will
ever help to fix. I see no particluar reason for
Sprint to spend any resources on keeping ANS's
exterior routing sane. So do not expect "advisory: AS690"
from us.
Of course, (as ICM _has_ AUP) we can always start
demanding NACRs from ANS. Just to make people who
make decisions there to wake up.
--vadim
To: nanog(a)merit.edu
Subject: AS690 use of multiple routing registries
Date: Fri, 26 May 1995 16:44:47 -0400
From: Steve Heimlich <heimlich(a)ans.net>
Status: R
Folks,
This note outlines changes to the ANS AS690 use of various registries
which comprise the Internet Routing Registry (IRR). [RIPE gang,
please forward to your mailing lists as appropriate].
Currently, the IRR consists of the following four well-known
registries: the RADB, the CA*Net registry, the MCI registry, and
the RIPE registry. AS690, to date, has relied exclusively on the
RADB for generation of its configurations. As a result, those
organizations which would naturally register in the MCI, CA*Net,
or RIPE registries have been making redundant registrations in the
RADB to ensure connectivity with ANS. This redundant registration
has been inconvenient for many, and leads to multiple copies of
route objects with inconsistent attributes.
As of next week, ANS will begin to use route objects from the
CA*Net, MCI, and RIPE routing registries. In order to do this, we
will first create an ANS registry (containing customers of ANS)
with "source: ANS" as its distinguishing attribute. Beginning with
next Wednesday's AS690 config run (changed from Tuesday due to the
U.S. Memorial Day holiday), we will prefer routes with AS690
advisories from these registries in the following order: ANS,
CA*Net, MCI, and the RADB. Once we verify that this has succeeded,
we will include the RIPE registry ahead of the RADB on next Friday's
config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for
config generation will eliminate the need for multiple registrations
of singly-homed routes.
Toward the end of June, we expect to have software running which
will eliminate the use of AS690 advisories. This software generates
an initial policy first by using registered advisories (a one-time
operation). Currently, this results in a 16,000 line aut-num object
for AS690. As this is somewhat unreasonable, we will be reducing
the number of per-network exceptions in favor of one policy per
home AS. As we approach the deployment of this capability, we will
be working with peer providers on arranging mutually acceptable
policies with AS690.
Steve
