204.82.160.0/22 invisible

Mon Sep 25 05:40:59 UTC 1995

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 at 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