I have and remain unconvinced and or confused 
The proposal allows
an operator to verify a valid origin AS for a given prefix (i.e. "config"
sorry if I'm being loose with the word) by using the DNS system with
"bgp.in-addr" extensions. I'm not sure which part of the random
route announcement problem that dnssec solves in this case? It can
help with the "are they indeed are who they say they are", but it
doesn't solve the "are they supposed to be doing what they said that
they're doing" case.
Has anyone benchmarked how long it will take to resolve 50,000 bgp.in-addr's
after a line hiccup or a "clear ip bgp *"? -Hank
Has anyone benchmarked how long it will take to resolve 50,000 bgp.in-addr's
after a line hiccup or a "clear ip bgp *"? -Hank
yes. current production bind can serve over 2,500 per second from a pc.
and it is trivial to preload cache. the arithmetic is left as an exercise.
randy
hank@ibm.net.il (Hank Nussbacher) writes:
Has anyone benchmarked how long it will take to resolve 50,000 bgp.in-addr's
after a line hiccup or a "clear ip bgp *"? -Hank
I think an important point is that the implementation need not authenticate
a path before it can use it. The vast majority of paths will not generate
authentication failures. This policy does allow the temporary propagation
of bad information, but the system can heal itself quickly. In the
meantime, it means that everyone else gets reasonable convergence time.
Tony