2 - The RADB has a lot of old, now obsolete, data maintained by others. Do
we have to ask each old maintainer to clean it out, or will it all be
cleaned up as the changeover settles down?
3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share
a non-trivial subset. Are there maintainers' tools for generating both
from a single database? If not, we will surely create errors of
This almost but not quite touches on what are (for me) the
big questions of the RADB, which are, firstly, in the absence
of really easy to use tools that keep router configurations
and the RADB in sync, of what use is the RADB, other than as
a "this is what things should have looked like a while ago"
debugging tool or in the cases of ISPs who configure their
routers from the RADB, the most likely reason for not being
able to reach network X ("gee, they haven't updated the RADB
and therefore you can't get there from here")?
Secondly, if the RADB and the world's routers are all in
sync, of what value is the RADB as something to protect the
world from weird announcements?
I don't know the answers to these, and they're not entirely
FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the
pond view) to be the most immediate and reliable over the many moons.
Thanks, Randy. We're trying, despite massive screw ups from
time to time (fat fingers Doran and so forth).
But the overwhelming problem with all avenues has been the NACR delay.
I agree. Looking back at routing problems reported to us
over the last several months in such a way that I saw them,
the overwhelming majority has concerned the PRDB not being
in sync with the rest of the world.
The next largest number of routing problems had to do with
customers' BGP peerings with SprintLink, and the bulk of
those problems involved singly-homed customers.