Allow me to clarify Curtis's remarks:
> 1 - When can do stop needing NACRs? Monday, i.e. effectively now?
Still need them. A lot of people are typing as fast as they can to
remove this requirement. Code takes time to write and debug.
_ANS_ needs NACRs or RADB updates for the time being.
If I were in Andrew Partan and company's shoes rather than
in mine, I would simply refuse to submit them.
Because ANS has this history of centre-of-the-universe
arrogance which I keep hoping the newer, nicer engineers
there are going to be able to undo and get rid of, even
though there are real risks involved in trusting one's peers
just as everybody else does.
The appropriate way to make routing clean and safe is
pointing out problems to one's well-meaning peers and using
bilateral and multilateral social pressure against one's
more aloof ones. Considering that DREN and DISA have *both*
been able to present a pretty clean set of routes to their
new peers with a bit of friendly help and some reminders
that this is an Important Thing To Do, I think we have
existence proof of this.
Just as a pair of data points: I was very very very keen on
having an RS (or RS-like device) at FIX-EAST last week in
order to help with the transition of those two fednets before
they cleaned up their routing. I now no longer see a need
to continue with the RS for that purpose.
The second data point: we (SprintLink) do peer
experimentally with the RSes at MAE-EAST, and asked
to be given all NETCOM routes given to us from the RS.
When I last checked, we were seeing clean information from
our direct NETCOM peering, but, as I pointed out to Jessica
Yu, there were some glaring problems with what the RS there
was giving us.
So, in my opinion, as far as a technology to keep routing
information clean among big providers, the RSes aren't
worthwhile at this time.
As far as a technology to keep routing information clean
between big providers and small providers at a peering
point, imho that is a matter for bilateral agreements
and other peer-to-peer and public pressures.
The only thing I see as potentially useful with the RSes,
unfortunately, is the possibility of working on a solution
to The Big Problem, which is keeping routing symmetrical
between any two big providers peering at lots and lots of
I see the primary use of a fully populated RADB as a tool
The fact that you see it as a tool for configuring your
network is simply interesting.