[167221] in North American Network Operators' Group
Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)
daemon@ATHENA.MIT.EDU (joel jaeggli)
Wed Dec 4 16:26:37 2013
Date: Wed, 04 Dec 2013 13:26:16 -0800
From: joel jaeggli <joelja@bogus.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>,
Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAH1iCirY+DPmeV9fjAUxcRQX3iz=Bonv4366Xhg6UAOa2McK-w@mail.gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--u6JBRttGTRLamJCEfoVn9c8bp9UHDoENe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12/4/13, 12:58 PM, Brian Dickson wrote:
> On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow
> <morrowc.lists@gmail.com>wrote:
>=20
>> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
>> <brian.peter.dickson@gmail.com> wrote:
>>> Except that we have a hard limit of 1M total, which after a few 100K =
from
>>
>> where does the 1M come from?
>>
>=20
> FIB table sizes, usually dictated by TCAM size. Think deployed hardware=
,
> lots of it.
> (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv=
6
> taking two slots of TCAM, IIRC. And a few other things also consume TCA=
M,
> maybe not as significantly.)
>=20
> (Newer boxes may handle more on some network's cores, but I don't belie=
ve
> it is ubiquitously the case across the DFZ.)
Table size growth has conveniently not outstripped the growth of
available fib sizes in a quite a long time. There doesn't appear to be
much reason to believe that won't continue baring us coming up with
novel ways to blow up the size of the DFZ. Managing to aggregate in some
way that respects your internal topology and addressing plan without
blowing up your route count is an exercise for the reader.
It's somewhat facile to relate fib size to the bounds of what ternary
cam chips you can currently buy since not all routers use cams for
longest match lookups.
> Brian
>=20
--u6JBRttGTRLamJCEfoVn9c8bp9UHDoENe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKfnfgACgkQ8AA1q7Z/VrLVjACeKobGl4jfI3D3i9AAzvykUI2a
Qa8AoIMujcSKzV0i7X5bWi5WWnvtFtu1
=cxqh
-----END PGP SIGNATURE-----
--u6JBRttGTRLamJCEfoVn9c8bp9UHDoENe--
