[173935] in North American Network Operators' Group
Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good
daemon@ATHENA.MIT.EDU (manning bill)
Thu Aug 14 00:24:01 2014
X-Original-To: nanog@nanog.org
From: manning bill <bmanning@isi.edu>
In-Reply-To: <DF794D6A-4984-4623-AA27-A25CD2721677@ianai.net>
Date: Wed, 13 Aug 2014 21:23:10 -0700
To: "Patrick W. Gilmore" <patrick@ianai.net>
X-MailScanner-From: bmanning@isi.edu
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Sprint used to proxy aggregate=85 I remember 128.0.0.0/3
the real question, imho, is if folks are going to look into their =
crystal balls and roadmap where the default offered is a /32 (either v4 =
or v6)
and plan accordingly, or just slap another bandaid on the oozing =
wound...
/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 13August2014Wednesday, at 21:15, Patrick W. Gilmore =
<patrick@ianai.net> wrote:
> Composed on a virtual keyboard, please forgive typos.=20
>=20
>> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian =
<ops.lists@gmail.com> wrote:
>>=20
>> Swisscom or some other European SP has / used to have a limit where =
they would not accept more specific routes than say a /22 from provider =
x, so if you 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.
>=20
> And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 =
archives for my [wrong then corrected] interpretation of ACL112.) Etc., =
etc.=20
>=20
> For stub networks, especially ones who are not as performance =
sensitive, this 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 was first sold in 1999. I'm impressed it =
has lasted this long, even with new sups. Time to start thinking about =
upgrading.=20
>=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 of bad side effects, such as less revenue when they =
don't pick you because you don't have the route.=20
>=20
> --=20
> TTFN,
> patrick
>=20
>=20
>>> On Thursday, August 14, 2014, Brett Frankenberger =
<rbf+nanog@panix.com> wrote:
>>> 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]tac
>>>>> tickets open for five years)? wonder why.
>>>>=20
>>>> 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)
