[173934] in North American Network Operators' Group
Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Thu Aug 14 00:15:47 2014
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <CAArzuotEitW18tNK+TAY8X7J_5RUeVJAABzvRdp0MQ5PG-qRxQ@mail.gmail.com>
Date: Thu, 14 Aug 2014 00:15:36 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Composed on a virtual keyboard, please forgive typos.=20
> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian <ops.lists@gmail.com> wr=
ote:
>=20
> Swisscom or some other European SP has / used to have a limit where they w=
ould not accept more specific routes than say a /22 from provider x, so if y=
ou wanted to take a /24 and announce it you were SOL sending packets to them=
from that /24 over provider y.
>=20
> Still, for elderly and capacity limited routers, that might work.
And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archi=
ves for my [wrong then corrected] interpretation of ACL112.) Etc., etc.=20
For stub networks, especially ones who are not as performance sensitive, thi=
s can help extend the life of their routers. But not everyone can make AGS+s=
work for years past their useful life or get "-doran" IOS builds. The 6500 w=
as first sold in 1999. I'm impressed it has lasted this long, even with new s=
ups. Time to start thinking about upgrading.=20
As for networks providing transit, those were highly unsound policies, IMHO.=
I specifically did not buy from Sprint then or Verio later when they did it=
, and I was not alone. Giving your customers less than full routes has lots o=
f bad side effects, such as less revenue when they don't pick you because yo=
u don't have the route.=20
--=20
TTFN,
patrick
>> On Thursday, August 14, 2014, Brett Frankenberger <rbf+nanog@panix.com> w=
rote:
>> On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote:
>> > > you mean your vendor won't give you the knobs to do it smartly ([j]ta=
c
>> > > tickets open for five years)? wonder why.
>> >
>> > Might be useful if you mentioned what you considered a "smart" way to
>> > trim the fib. But then you couldn't bitch and moan about people not
>> > understanding you, which is the real reason you post to NANOG.
>>=20
>> Optimization #1 -- elimination of more specifics where there's a less
>> specific that has the same next hop (obviously only in cases where the
>> less specific is the one that would be used if the more specific were
>> left out).
>>=20
>> Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the
>> latter can be left out of TCAM (assuming there's not a 10.10.6.0/23
>> with a different next hop).
>>=20
>> Optimization #2 -- concatenation of adjacent routes when they have the
>> same next hop
>>=20
>> Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop,
>> leave them both out of TCAM and install 10.10.14.0/14
>>=20
>> Optimization #3 -- elimination of routes that have more specifics for
>> their entire range.
>>=20
>> Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23,
>> 10.10.6.0/24 an 10.10.7.0/24 all exist
>>=20
>> Some additional points:
>>=20
>> -- This isn't that hard to implement. Once you have a FIB and
>> primitives for manipulating it, it's not especially difficult to extend
>> them to also maintain a minimal-size-FIB.
>>=20
>> -- The key is that aggregation need not be limited to identical routes.
>> Any two routes *that have the same next hop from the perspective of the
>> router doing the aggregating* can be aggregated in TCAM. DFZ routers
>> have half a million routes, but comparatively few direct adjacencies.
>> So lots of opportunity to aggregate.
>>=20
>> -- What I've described above gives forwarding behavior *identical* to
>> unaggregated forwarding behavior, but with fewer TCAM entries.
>> Obviously, you can get further reductions if you're willing to accept
>> different behavior (for example, igoring more specifics when there's a
>> less specific, even if the less specific has a different next hop).
>>=20
>> (This might or might not be what Randy was talking about. Maybe he's
>> looking for knobs to allow some routes to be excluded from TCAM at the
>> expense of changing forwarding behavior. But even without any such
>> things, there's still opportunity to meaningfully reduce usage just by
>> handling the cases where forwarding behavior will not change.)
>>=20
>> -- Brett
>=20
>=20
> --=20
> --srs (iPad)
