Initially, I thought that you were right, but on second thought
I see a problem. If a peer of yours is giving someone third party routes,
this filtering will blackhole traffic. While your peer should not be
giving these routes with your router as the next hop, it will happen
and we need a way to debug it.
Direct peering - use next-hop-self. May be problematic in that it will
load your FDDI more (esp problematic if you've got a NetEdged FDDI
RA peering - this is a bit more of an issue. Suppose A gives/sells
some routes to B through the RA including those of C who B peers
with through the RA. A doesn't peer with C. The RA will send C's
routes to A with a next hop of C's router and they'll presumably be
black holed. Obviously the simple solution in this case is for A and
B not to be so ridiculous and direct peer or use a serial lead or
something, but I wonder if there are other less obvious problems.
One of the nasty things about filtering is that a non-obvious RA
misconfiguration might lead to blackholing, possibly hurting other networks
than the one responsible for the misconfig. Maybe gated can be hacked
to always return the next hop of intermediate peer (B here). Mmmm...
Tool for configuring filtering straight from the RA anyone?