So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today

Thu Aug 14 02:59:39 UTC 2014

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.

Still, for elderly and capacity limited routers, that might work.

On Thursday, August 14, 2014, Brett Frankenberger <rbf+nanog at 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.
> >
> > 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.
>
> 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).
>
> 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).
>
> Optimization #2 -- concatenation of adjacent routes when they have the
> same next hop
>
> 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
>
> Optimization #3 -- elimination of routes that have more specifics for
> their entire range.
>
> 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
>
> Some additional points:
>
> -- 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.
>
> -- 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.
>
> -- 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).
>
> (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.)
>
>      -- Brett
>

-- 
--srs (iPad)