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 <patr...@ianai.net> wrote: > Composed on a virtual keyboard, please forgive typos. > >> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian <ops.li...@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+na...@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)
