Re: [Idr] On FIB sizing...

[Jeff Wheeler <[e-mail]>]

On Sat, Dec 15, 2012 at 9:25 PM, Tony Li <[e-mail]> wrote:
> As an aside, FIB sizing only varies loosely with the maximum number of
bits in the address because the FIB can be constructed to hold only
prefixes.  Thus, what's more important is the average and distribution of
prefix lengths.

Certainly true, but you reduce power/heat/die area at the expense of
complexity.  I would say that vendors have been doing this long enough to
have pretty much mastered it, but there are products on the market right
now that have sub-optimal FIB scale and will deliver greater FIB scale
through software upgrades, once the software people for these boxes have
time to actually implement the needed improvements.

It is also the reason why people worry about whether or not their box of
choice will work right if they decide to configure /120s or whatever.  My
results have been good, but a few people claim that specific routers do not
work well in such circumstances.  They are probably not wrong.

> Thus, (for a core router) the choice of /128 is largely irrelevant when
remote prefixes are all /64 and shorter.  For a datacenter switch that has
to store possibly many /128's, this is more of an issue, but is offset
because *there is no ARP cache to deal with*.

It would be nice if that were true.  Unfortunately you are not correct.

There is no router that will forward based on an L2 address encoded into a
global IPv6 L3 address, even as an optional configuration knob on the
subnet, egress interface, or adjacency table entry.  I wish such router
would hurry up and exist because it is a smart idea that has just not been
implemented in products that are shipping.

Most routers even need to install link-local address L3 to L2 mappings into
the data-plane even though this should usually be unnecessary.  If you
think this means that the number of L3 to L2 mappings in the FIB is
effectively doubled for subnets where the attached machines all have 1
global IPv6 address and 1 link-local address, you are right.  It means a
router that claims to have room for 2000 ND entries can only support 1000
machines in practice.

If you think there is no "ARP cache" and thus less problems to consider
with IPv6, you should learn about why Cisco has implemented a knob to limit
the number of ND entries that can be used on a per-interface basis.  ND
cache size, churn, exhaustion attacks are a serious concern that operators
will have to deal with once IPv6 adoption grows to the point that
IPv6-based DDoS becomes common.  Most vendors are totally ignoring this
problem and it worries many of us.  It is especially concerning on
platforms like Cisco SUP720 where an attack of this nature will break not
only IPv6 but also IPv4.


My point is, raising the size of the AS number to 64 bits, or some other
ridiculous size, really would not have had data-plane cost the way IPv6
address sizes do.  The only place AS numbers are used in the data-plane is
netflow, and abstractions can be used in place of real AS numbers there.

I am not advocating any scheme that would again raise the AS number space
size.  I'm just pointing out that it would not increase the cost of FIBs.

If anyone thought that hierarchical AS number allocation was a smart idea
and private AS numbers should be eliminated by simply making enough global
AS to satisfy every org with as many as they want (Randy Bush's position),
then hopefully these people spoke up at the time 4-octet AS numbers were
standardized.

-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts