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

[Aris Lambrianidis <effulgence () gmail com>]

I think you mean what is best described here:
http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

--Aris

> Suresh Ramasubramanian <mailto:ops.lists () gmail com>
> Thursday, August 14, 2014 04:59
> 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 () panix com>
>
>
> Brett Frankenberger <mailto:rbf+nanog () panix com>
> Thursday, August 14, 2014 04:49
>
> 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
> Patrick W. Gilmore <mailto:patrick () ianai net>
> Thursday, August 14, 2014 01:53
> On Aug 13, 2014, at 16:42 , Randy Bush <randy () psg com> wrote:
>
> > half the routing table is deagg crap.  filter it.  
>
> We disagree.
>
> Just because you don't like all more specifics doesn't mean they are useless.
>
> Not everything is about minimizing FIB size. (And RIB size hasn't been relevant for years.) People pay an ass-ton of 
> money to save a few ms off their RTT, if a more specific will allow packets to travel LHR->FRA directly instead of 
> packets going from LHR -> SFO -> FRA, they are useful even if there is a covering prefix.
>
>
> > 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.
>
> Randy Bush <mailto:randy () psg com>
> Wednesday, August 13, 2014 22:42
> half the routing table is deagg crap. filter it.
>
> you mean your vendor won't give you the knobs to do it smartly ([j]tac
> tickets open for five years)? wonder why.
>
> randy
> Suresh Ramasubramanian <mailto:ops.lists () gmail com>
> Tuesday, August 12, 2014 18:10
> 512K routes, here we come. Lots of TCAM based routers suddenly become
> really expensive doorstops.
>
> Maybe time to revisit this old 2007 nanog thread?
>
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog
>
> FYI nanog -
> https://puck.nether.net/pipermail/outages/2014-August/007091.html
>
> [outages] Major outages today, not much info at this time
>
> Teun Vink teun at teun.tv
> Tue Aug 12 11:42:05 EDT 2014
>
> Hi,
>
> Some routing tables hit 512K routes today. Some old hardware and
> software can't handle that and either crash or ignore newly learned
> routes. So this may cause some disturbances in the force.
>
> HTH,
> Teun
>
> -----------------