Some additions On September 25, you wrote:

Poking at this futher, Sprint is announcing 204.82.160/22; Digex is behind ANS; this route is not in the RADB; and since ANS insists on all routes being in the RADB, they are not accepting it, so Digex is not seeing it.

Ive statically nailed up this route to sprintlink, for the week of this event. It will be removed either when the week is up, or as soon as sprintlink/sean requests its removal. 206.82.160/22 for the record.

Fix: Either get ANS to not insist on all routes being in the RADB or submit an update to the RADB & wait for ANS to regenerate their configs.

While the RADB is flawed (overloaded to the tune of about 30k routes and not including routes such as this one) I dont think ans is quite ready to hang it up... so those of us who rely on the RADB, or (in my case) rely on transit provider based on the radb, we'll have to take these one at a time. Hopefully without the "anti-trust, im going to sue you, guess I have to be the martyr" bullshit.

Kai: Please don't widly accuse folks before poking into the facts. --asp@uunet.uu.net (Andrew Partan)

and as to this

...

Correct. I have other networks in 204, so above was a typo. Also correct: he (rather cryptically) said Sprint wouldn't filter outgoing (hence customer-owned) routes, but he encouraged OTHER providers to do it like Sprint: filter incoming routes by the rules anounced: this has the same effect, but now Sean could point at Digex (should they employ such a filter) "I didn't do it, man!"...

Ill have you know that the filter list im working on looks nothing like the sprintlink one in any way..least not after I took those ugly comments out ;) Ed