[snip]
I've got a number of other nets to be moved shortly, so I'd really like
to be clear on how this works. It appears that very few nets rely on the
data in the RADB, or take updated data from the RADB in near-real-time
fashion.
When last I dealt with this matter (96), ANS happily listens to
minor IRR policy stuff in a timely (hours?) fashion, but still
manually configured what they considered a "move" from AS to AS.
They appeared -at that time- to consider adding sessions to an AS
with which they have direct sessions a "move" and updating the
IRR was insufficeint. I had hoped that went away with "advisory"
lines.
Maybe someone at ANS would like to comment about the current
implementation?
Cheers,
Thanks to everyone who posted messages and/or sent me private mail on
this issue. It has been resolved, and the information gathered here
helped a great deal.
We ultimately got a conference call today with an NOC engineer from the
provider upstream of the net, and a fellow at the ANS NOC, and got the
route added in. The fellow from ANS indicated the routes are picked up
on Wednesday (not sure what time) for the Thursday update, and on Sunday
for the Tuesday update. It's possible the RADB update for this prefix,
which was made Wednesday, occurred after ANS had pulled the data. This
is all second-hand, though. Perhaps someone from ANS will confirm or
deny...
Dan
When FDT got it's CIDR block from ARIN several months ago, I had to call
ANS and complain that they were ignoring my entry in radb.ra.net. Seemed
awfully primitive.
---dont't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________