[snip]
> It seems either option would be better for not breaking connectivity than
[snip]
Flatly, in my experience breaking connectivity for the apathetic
or clueless folks abusing the commons is the only way to get them
to change behavior. At worst, your own customers are inconvenienced
while the other party gets rulers and prepares for a locker room
measuring contest, and you relevent first poking a hole in a policy.
At best, clued technical people trapped in the remote networks'
organization get an "I told you so" reason to Do The Right Thing.
With the option of filtering on the RIR minimums, I'm not terribly worried
about breaking connectivity to the people announcing all /24s instead of
their /19. Broken connectivity for them is probably the only way they
will ever look at cleaning up their announcements. The organizations that
are hurt unnecessarily by filtering on the RIR minimums are the ones
multi-homing with smaller PA space or announcing a few more specifics
here and there for traffic engineering.
You can rathole the discussion on specific implementations and
memory structures all the livelong day, but that won't change any
individual operator's behavior. Are your confident YFRV will
deliver any updated feature[s] in a timescale that fits your own
networks' projected FIB & memory crush? Will it actually address
the problem or just move the curve a little further into the future?
Cheers,
Joe
I'm not confident on getting any change implemented, or of it's
effectiveness. I'm just trying to generate ideas to get people thinking
of better methods of reducing routing table bloat without hurting
everyone.
That sounds very nice, what box is that ?
I can’t remeber our C rep mentioning anything about that, but in C’s defense
I’m not always paying attention.
how about a filter between in-rib and what you actually crank
through the churning clothes washer? pass on the in-rib, calc on
the phyltered data. so when shorter prefix is withdrawn, you can
look for next best candidate.
Possible, but decidedly non-trivial. Recall that if you're going to
phylter before the RIB, then you'll have to reflect that in your BGP
advertisements too. Any route caught in the phylter must be
withdrawn if it has been advertised.
i am not happy with just announce from input, but note that it would
remove this problem. it would also throw the best path baby out with
the bathwater. i don't think we are ready for that.
note that my original proposal/case some years back allowed a
number of flavors of phylter, longer+same-next-hop,
longer+same-as-path, longer+same_origin-as.
Full time employment for BGP geeks. On the flip side, the number
of variants of expert systems that you're proposing suggests that
there be one configurable mechanism. Complexity++; ;-(
and even more hidden policy, which uncle tim warns us will lead to a wsj
article some day (appended).
but i am slightly more fearful of the cost of routing table growth and
table churn. slightly.
Despite Tim's comment, this is not the result of "non-standard"
policy languages. In fact, it's the result of truly expressive
policy languages.
i am less sure of that. tim's metarouting algebras do not seem to lack
expressiveness. they just allow us to define policy languages that do
not let us express stupid things.
Any language that forces all of us to make globally consistent
choices is not going to mandate aligned policies, which is going to
necessarily result in deeply restricted systems.
i am not sure global consistency requires global homogeneity. it is more
likely to require some visibility/transparency which maybe the folk
doing partial-reveal crypto have a leg on.
but, interesting as this is, i fear we have drifted a bit afield from
describing hacks to allow us more control of what moves from our ears to
our ribs and then what fibs we tell.
With the option of filtering on the RIR minimums, I'm not terribly
worried about breaking connectivity to the people announcing all
/24s instead of their /19. Broken connectivity for them is probably
the only way they will ever look at cleaning up their announcements.
The organizations that are hurt unnecessarily by filtering on the
RIR minimums are the ones multi-homing with smaller PA space
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space. OTOH, most providers are happy to give out as much PA space as you need, as long as you pay for it. If you only have a /25 today and you need a /24 for your PA route to be heard, call your upstream's sales droid and request a /24.
or announcing a few more specifics here and there for traffic
engineering.
Such folks would lose the effects of their TE, if their TE routes are longer than RIR minima, but not connectivity in general. Also, TE is only useful a few AS hops away, so the filter being discussed could be combined with another solution being proposed to allow longer-than-RIR-minima routes with a short AS PATH.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from one
of your providers even if you only need 1 IP address:
NPRM 4.2.3.6
"This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements."
Sucks to be them. If they do not have enough PA space to meet
the RIR minima, the community has decided they're not "worthy"
of a slot in the DFZ by denying them PI space.
Not true, there is an ARIN policy that allows you to get a /24 from
one of your providers even if you only need 1 IP address:
NPRM 4.2.3.6
"This policy allows a downstream customer's multihoming
requirement to serve as justification for a /24 reassignment from
their upstream ISP, regardless of host requirements."
If the PA /24 is under 199/8 or 204-207/8, then the filters being discussed would allow their advertisement through, because ARIN's minimum allocation for those blocks is /24. In ARIN's 22 other /8s, the filters would not because the minimum is /20 (or /22, for 208/8).
Let's also keep in mind that if other folks block a PA more-specific, the site doesn't lose connectivity unless they lose their upstream connection to the LIR that assigned them the block. I suspect that many of them already see that behavior today, at least partially; we're really discussing making it a near-complete outage versus a semi-outage. That's life if you don't qualify for a real routing slot via PI.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
I oppose wholesale filtering by allocation size policy as an acceptable metric for reducing your RIB.
There are legitimate reasons to announce only /24s within a /21 or /22 PI allocation, for example. Perhaps an org has diverse networks in multiple cities and doesn’t want to be beholden to upstream PA space. One may argue, “build a proper network, noob,” but there may not be a business case for sufficient interconnect between sites to have a consistent origin AS.
If one could filter in such a way that one only aggregated prefixes back to their allocated size when the AS path (or even origin AS) is the same, then you won’t be breaking anyone, and will put the kibosh on the noobs who deagg for no good reason (but no vendor is giving us a ‘filter-stupid’ knob yet).
Filtering/aggregating outside your local RIR seems like a better plan to me (for some networks, anyway). You’re a whole lot less likely to have a bad/missing path, and you still have sufficient knobs to engineer most outbound flows.
-Kevin Blackham
(recently moved from provider to end network using non-XL PFC)
Maybe this is a dumb question, but why isn't there a BGP option to just
filter more specific routes that have the same AS path as the larger
aggregate? This would allow the networks that announce more specifics for
traffic engineering to still accomplish that, while throwing away the
garbage from someone else that decides to announce their /19 as 33 routes
for no apparent reason. Sure, this would fail if a network decided to only announce /24's for example without a larger aggregate, but how many networks are really doing that?
Forrest
There's a couple of feature requests open at Cisco that would do this. Rodney Dunn (at Cisco) pushed quite hard for these but couldn't get any traction. As he's previously pointed out it would have if people would vote for them (attach a case to).
FORWARDED MESSAGE:
Rodney Dunn wrote:
Take your pick.
CSCsa45474 Ability to block overlapping BGP prefixes from being installed in RIB
or better:
CSCsa46049 IOS RIB should not install overlapping routes with same next hop
I'm willing to bet that Cisco's sales team is pushing back a little on
this enhancement. Given the choice between prolonging the usefulness of
Sup2 for another year or two versus selling a massive amount of new
Sup720-3BXLs, I'm betting they'll do the later.
As long as enough NSPs don't filter on RIR minimums, there's still a pretty good chance that when a small PA multihomer's IP space provider's connection is down, traffic routed towards that provider will get rerouted to their other provider(s).
Breaking PA /24 multihoming would be unfortunate collateral damage.
Perhaps someone could use the data from the cidr-report and RIRs to create a precision targeted prefix-list intended just to block unnecessary more specifics rather than across the board on RIR minimums?
You could even do two different versions. A loose version that just throws out covered subnets with same as-path and a BOFH version that throws out all apparently gratuitous subnetting smaller than RIR minimums, but not all smaller than RIR minimum routes.
I just wonder how huge the list would be and what the CPU and config size damage would be.
On the flip side, the number