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

Thu Aug 14 02:49:51 UTC 2014

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