[arin-ppml] A challenge to the assumption that a big DFZ is aproblem

[Leo Bicknell]

In a message written on Tue, Dec 15, 2009 at 01:02:08PM -0800, Ted Mittelstaedt wrote:
> What I'm saying is that it seems to me that there is no inherent barrier
> in the silicon to coming out with routers that would do a much larger
> DFZ  TOMORROW.  Granted, TODAY's designs might not scale up - but
> is that a silicon problem or simply that more R&D is needed to find
> better (or cheaper) router designs?

You are correct from a technology point of view.  I believe TCAM
designs can scale to a much larger routing table, perhaps with a
corresponding increase in cost.  Beyond that history tells us some
other solution will be found.

However, R&D almost never generates cheaper designs, at least in
Rev 1.  Perhaps in revs 2 and 3 and 4 they get cheaper, but rarely
does an advance end up cheaper out of the gate.

Plus, there is lead time.  Evolutionary designs take ~3-5 years to
spin out.  Routers you will buy in 2013 are all but done deals from
a design perspective.  What remains is to work out manufacturing,
testing, code, etc.  If you're looking at something totally new
then you're probably in the 5-7 year timeframe on the short end.

So if the question is, can we support a 10 million route FIB in
2020, the answer is probably yes.  If the answer is can we support
a 10 million route fib in 2015, the answer is almost as firmly no.

The TCAM is a shared resource in most designs.  Any/all of the
following share the same resource:

IPv4 Route
Ipv6 Route
ACL
ARP Entry
MPLS Label
IPv6 ND Information
CLNS Neighbor Information

Those that are really worried about this aren't worried that the IPv4
routing table might grow from 300,000 today to 600,000 in 2015, or that
the IPv6 routing table might grow from 2000 today to 100,000 in 2015.
Nor are they worried about the MPLS table growing from 1,000 entries
to 20,000 entries as MPLS VPN's take off.  However, adding up all of
those in the shared resource creates a grim picture.  It would appear
all of the people planning for those three separate things are all but
assuming the others are 0.

> But, is the economics of it our responsibility?  What is ARIN's
> charter, folks?  Are you saying we should modify addressing policy
> based on costs of hardware, or based on what it's POSSIBLE for
> hardware to do?

In the long (10+ year) view, absolutely not.  Do what's right, and the
vendors will sort it out.  In the short term view, under 5 years for
sure, probably under 10, and maybe under 15, the hardware must be
considered.  It need not dicate, but to ignore it would be excessively
foolish, and hardly rise to the standard of being a good steward.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091215/7f9121db/attachment.sig>