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

["Patrick W. Gilmore" <patrick () ianai net>]

Composed on a virtual keyboard, please forgive typos. 

> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian <ops.lists () gmail com> wrote:
>
> 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.

And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archives for my [wrong then corrected] 
interpretation of ACL112.) Etc., etc. 

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. 

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. 

-- 
TTFN,
patrick


> > 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.
> > >
> > > 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)