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

Thu Aug 14 04:23:10 UTC 2014

Sprint used to  proxy aggregate…   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 at ianai.net> wrote:

> Composed on a virtual keyboard, please forgive typos. 
> 
>> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian <ops.lists at 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 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)