[ppml] Longer prefixes burden the FIBs of DFZ routers

[Stephen Sprunk]

Thus spake "Leo Bicknell" <bicknell at ufp.org>
> I'm quite afraid this sounds like early IPv4 routers.  They did
> Class A's, B's, and C's quite well, and some of them when
> you put in other length prefixes fell over.  I suppose it looked
> like a good trade off for the software and hardware of the day;
> and in fact it might have been the right choice to get us where
> we are today.  Those designs didn't last well though, and got
> fork lifted out when a problem occurred.

I don't remember it occurring the way you describe.  In the early 90s we 
needed software upgrades to support CIDR-aware protocols due to address 
space and routing table issues, which was painful but didn't require a 
forklift, and in the late 90s we needed hardware upgrades needed to switch 
from route-caching to FIBs due to the inversion of the 80/20 rule, which did 
generally require a forklift.

> I'm afraid it would have to be a global policy to mean
> something to the vendors, but perhaps a "under no
> circumstances will RIR's require prefixes longer than /XX
> before 2015" might be a way to reduce deployment costs.

That wouldn't help, AFAIK, since internal routes are already up to /128 and 
if forwarding packets to those destinations puts more strain on routers than 
forwarding to a /32 or even /64, it'll become a (perhaps unintentional) DDoS 
attack vector.  The IETF has told vendors to not optimize for any particular 
route length, and so far it appears they're heeding that advice.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov