On Sun, 9 Sep 2007, Joe Provo wrote:
On Sat, Sep 08, 2007 at 05:50:25PM -0500, Forrest wrote: [snip]
It seems either option would be better for not breaking connectivity than [snip] Flatly, in my experience breaking connectivity for the apathetic or clueless folks abusing the commons is the only way to get them to change behavior. At worst, your own customers are inconvenienced while the other party gets rulers and prepares for a locker room measuring contest, and you relevent first poking a hole in a policy. At best, clued technical people trapped in the remote networks' organization get an "I told you so" reason to Do The Right Thing.
With the option of filtering on the RIR minimums, I'm not terribly worried about breaking connectivity to the people announcing all /24s instead of their /19. Broken connectivity for them is probably the only way they will ever look at cleaning up their announcements. The organizations that are hurt unnecessarily by filtering on the RIR minimums are the ones multi-homing with smaller PA space or announcing a few more specifics here and there for traffic engineering.
You can rathole the discussion on specific implementations and memory structures all the livelong day, but that won't change any individual operator's behavior. Are your confident YFRV will deliver any updated feature[s] in a timescale that fits your own networks' projected FIB & memory crush? Will it actually address the problem or just move the curve a little further into the future?
Cheers,
Joe
I'm not confident on getting any change implemented, or of it's effectiveness. I'm just trying to generate ideas to get people thinking of better methods of reducing routing table bloat without hurting everyone. Forrest