Re: Route table growth and hardware limits...talk to the filter

[Forrest <forrest () almighty c64 org>]

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