[ppml] Longer prefixes burden the FIBs of DFZ routers

[Robin Whittle]

Hi Leo,

You wrote, in part:

> In the IPv4 world we have /32's for loopbacks, /24-/29's for "critical
> infrastructure", nameservers, management servers, and the like.  In
> some cases /30 or /31's may be carried throughout some of the network
> depending on how it's broken up internally.
> 
> Most IPv6 networks have some similar situations.  It may be /64's
> for critical infrastructure, /128's for loopbacks, and the like.

I didn't mention these, because I assume - perhaps wrongly - that
these don't carry the burden of Internet traffic.  It is my
impression that when an FIB in a router is handling a packet which
matches a /32 prefix which is for that router's IP address, or some
other router's IP address, that the packet is most likely to be a
BGP message between the routers or some configuration, logging
traffic etc.

Based on this, I figure it is not such a problem if the router's FIB
takes a few more memory read cycles to classify the packet.

> The way I boil down what you're saying is that "more bits of address
> space require more expensive hardware".  That's surely true.  

Yes - so I am keen to see address assignment policy for PI space not
place too much of a burden on routers in the future.

> We
> also have a nice history of manufacturers getting caught on the
> wrong end of an assumption, vendors in the past who had lookups or
> cache's built around sizes that did not end up matching real world
> deployment.

If I was designing a router - which I am not - I would want to know
what length prefix to optimise the performance for.  It would be no
good saying "Sometimes the router needs to handle /128 so the router
must be optimised to forward packets to /128 prefixes" when in
reality, most of the traffic would be to /32 to /48.

The costs, complexity and power dissipation of optimising for /128
would surely lead to a more expensive an more unfriendly outcome
than for something which was optimised for /48, but could do /128
less efficiently.


> We're also early in IPv6's life.  While we can't make it too expensive
> to deploy, we have to keep in mind the technology to foward it is
> going to get cheaper and cheaper over time.  I can only imagine the
> discussions back in 1986-1988 over how you forward a /32 bit address
> space when 32 bit CPU's were brand new, memory cost a fortune, etc.


I don't think that the last three decades of extraordinary progress
in semiconductors can be used as a guide to the next decade or so.
Current technologies are pushing fundamental physical limits, not
just the ability to manufacture things smaller.  There is only
limited prospect for making things faster, cheaper, less power
hungry etc. by reducing the transistor size further.


> At the end of the day, the thing I worry about most is locking into
> particular sizes.  If the vendors are told by the IETF, the RIR's,
> and/or their customers "we only assign /48's, lookups longer than
> that can be "expensive" and some event happens in the future to
> change that assumption the results can be deadly.

I think it would be a very good idea for the IETF and the RIRs to
decide, very carefully on something exactly like this.  I think the
IETF and the RIRs should be able to decide that under no
circumstances would IPv6 address policy in the next decade or two
require DFZ routers to look at any more than 48 bits of address for
Internet traffic.

It shouldn't be hard to decide that such a limit is realistic.  Then
routers can be built to efficiently handle this - to be optimised
for actual traffic in for foreseeable future, not some much more
expensive and unnecessary goal, such as being optimised for /64 or /128.

 - Robin