- Test - lists.nanog.org

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by Paul Vixie 29 Sep '01

29 Sep '01

Here we go again, but isolated and clearly this time: > Sprint had valid reasons for filtering. ... ^^^^^ Oh yeah? Did they think so? Who else has any voice in whether their reasons were valid? Frankly my dear, if Sprint or any other provider wanted to filter all prefixes containing an odd number of bits, and if they thought they had a valid reason for doing so, then by definition, their reasons would be valid. *Our* opinion of the validity (or not) of their reasons would be *irrelevant*. MIBH used to run with prefix filters. It didn't stop much but what it did stop was worthless -- not just people chopping up their ARIN blocks, people doing cheap distributed load balancing by emitting a prefix from multiple locations as a way to do cheap distributed load balancing(*), but erroneous garbage that never should have been there, and so, wasn't. At least in our view of the net. Our customers were happy, so, so were we. (*) if you want to do cheap distributed load balancing by faking multihoming of a prefix, you'll need swamp space, which seems like a small fence to climb.

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

Patrick writes: | >Wouldn't it have been easier for small ISP to just aggregate? | >I mean, /19s got through after all! | | No, it would not have helped. Assume the prospective customer has a link | to UUNET and a /24, but wants a second link for [insert reason]. He now | goes to SmallISP.com and asks for info on getting a second T1. Then the | Sprint sales guy calls him and mentions that IF AND ONLY IF he buys a line | from Sprint, will Sprint hear his /24. Let's see. Firstly, this is a valid point, although I wonder how Sprint's sales person could possibly know she or he should call the customer in the first place. Unless Sprint is known to employ psychics, this seems like a bit of a stretch in producing a bete noire. Secondly, /24 is not a small ISP, but wants a small ISP to back-up connectivity to UUNET. Valid goal. However, asking small ISP to ensure the world hears the hole in UUNET's CIDR block is not a good solution. Instead: 1. this is one reason why NAT was invented in the first place, and (hopefully) NAT is feasible for /24 (which is not an ISP) 2. where NAT is impractical or even undesirable, Tony Bates and Yakov Rekhter have a solution in RFC 2260 tailor-made to this situation 3. the maximum 254 things in the /24 can be renumbered into small ISP's PA space and announced to UUWHO with a constraining (set of) community(ies) (NAT, incidentally, was also invented to make renumbering easier) 4. "creative value-added approaches to this problem are sold for $" If the premise that /24 is not an ISP is false, then it should renumber anyway into PA space which is readily available and a generally understood cost of business for transit providers/ISPs. Remember that the /19 boundary is both aligned with RIR policy, which with its slow-start mechanism and fee structure is a really low barrier for a prospective ISP while still putting some costs on consumption of address space, and also small enough that it's not a deadly pain to renumber anything containable by a longer prefix, even without the assistance of NAT. | NOTE: I am not saying this is good or bad, simply saying that what you | suggest would not be useful in this situation. If I cover all the bases, exceptions, and gotchas I will write fewer individual messages but my heaven will they ever be lonnnnnnng! Market research indicates that this is not desired. Sean. PS: | "I realize that this is hard for you to wrap your brain around," but please | believe there may actually be other people on the planet who have the | brains to understand what they are doing and perhaps make a different | decision than you made for a good reason. Requires evidence, and sometimes is undone by subsequent messages. I hope you'll note my tone varies considerably in my various replies to people.

2 1

Why filtering? (was Re: Verio Peering Question)
by smd＠clock.org 29 Sep '01

29 Sep '01

Historical notes, rather than disagreement follows: Jeff McAdams writes: | Filtering on prefix length? There's just no solidly backed up reasoning | to support it that I've heard. 1. it was easy to do (although the EACL was a little hairy) 2. there wasn't a flap-damping choice at the time Note that the network I'm associated with now does RIPE-210 and applies it uniformly. And we figured that out ourselves, some years ago. I think it may have something to do with the fact that even less-experienced people understand that rapidly flapping announcements are (a sign of something) bad. :-) We've also learned that table size just makes a problem more likely to occur in the steady state, and have mitigated against "great big change" events with things like soft resets and checkpointing. Constraining size is now known to be an indirect treatment of the illness best expressed as "too dynamic a network". Sean.

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by Patrick W. Gilmore 29 Sep '01

29 Sep '01

At 10:12 PM 9/28/2001 -0400, Sean Donelan wrote: > >> The global routing table is hereby capped at 125K routes. After that, >> if you want a route, you have to pay somebody to give up theirs. > >Of course, we could adopt geographic allocations. North American is >still working on (+1) in e.164 space. We could shrink the global >route table to a few thousand routes. There are many prefixes which are demonstrably useless in the global table (e.g. most of 7046). If you are really interested in reducing the size of the table, why not go after those? Instant gratification and all that. But I thought the problem is not *size* of the table, but *changes* in the table. With zero updates, a BGP table of double the current size would not bother any core router on the 'Net today. So, let's work on things like progressive flap dampening. I believe you suggested this before, Sean? -- TTFN, patrick

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

| > ip as-path access-list 1 permit _badguy_ | > | > route-map fix-badguy permit 10 | > descr proxy-aggregate the networks who are "holey" | > match as-path 1 | > | > router bgp my-as | > aggregate-address bad.guy.blo.ck1 255.255.224.0 as-set suppress-map fix-badguy | > aggregate-address bad.guy.blo.ck2 255.255.224.0 as-set suppress-map fix-badguy | > ... | | And one aggregates a lone /24 with what? Oh yay, a bona fide techical question. The answer: ACL 1 need not match only one AS as-set is there to deal with matches on multiple AS paths since we want to avoid looping announcements. conveniently, not only does it handle the case where ACL 1 matches lots of AS paths containing _X_, it can equally handle the case where ACL 1 matches lots of AS paths containing _Y_. Next time I use the example I will remember to make ACL 1 longer, and change "bad.guy.blo.ck1" (etc) into something along the lines of "poo.rag.gre.g81", but perhaps more aesthetically pleasing. Sean.

1 0

Too many people named Sean...
by James Smith 29 Sep '01

29 Sep '01

For a while I thought he was arguing with himself... ...need caffeine.... ;-) James H. Smith II I speak for myself, that gets me in enough trouble...

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

| The only people who complained were Sprint customers. They always | had the same story, but the filter's don't apply to us. "_Sprint_'s filters don't apply to you. These are _my_ filters." Sprint has had stupid customers, just like everyone else. "If you become a customer[*] of mine, then _my_ filters won't apply to you either." [*] here are our prices for transit, and we have a special deal where for just $XX.99 _my_ filters no longer apply to your networks Oh wait, capitalism is evil and selling filter-exceptions is also immoral (like Indulgences), so forget I mentioned it. Let's go back to whether or not I'm a lying corporate shill and an evil greedy bastard, that's more fun than trying to figure out how to approach non-technical problems presented by the marketplace. | Upon further investigation, they always found they didn't | need to announce those more specific routes. With a little extra | work, they figured out how to announce their registry allocated block. Great, so the plan to distribute the education of the masses off my desk and onto the desks of people like yours worked perfectly. | If Sprint had used a consistent route announcement policy, their | customers could have reduced their use of the global routing table | must sooner. It was consistent, just not symmetrical. It was deliberate and an attempt to get others to filter likewise, which would have accomplished exactly the same thing as symmetrical filtering would have, only with protection from Sprint folks deciding that filtering their customers might cause them to be unhappy and go elsewhere, since there was no expectation that anybody else [*] would filter their customers. | "save the | Internet, unless you pay Sprint extra then its all you can eat | night at the village commons." Shut up and send me a cheque. Sean. [*] of consequence

1 0

good advice for operators (forwarded, with commentary)
by smd＠clock.org 29 Sep '01

29 Sep '01

The muckslinging here reminds me of the break between the operators and the IETF -- the users go on and on about the evil motives of the operators big & small, and demonstrate their lack of understanding or lack of social skills in the process enough that operators decide it's no longer fun to play. I got a message from an operator people would recognize that is interesting, useful, and relevant to operations. Hopefully the good advice in here won't get lost just because the author in question is on the "filtering side". "announce ... aggregates [, develop a] sensible policy [, and acquire] /20's for each location." Who can argue with that? Those of you who feel that regional & local ISPs are being persecuted, please tattoo that advice on your forehead, backwards, so you can see it reflected in your monitor next time before you flame on NANOG about how horrible filtering long prefixes is. My correspondent and his or her colleagues will appreciate the reduction in stomach acids which are not good for any engineer's duodenum. Sean. PS: Well, it's even better if you never announce the more specifics in the first place, imho, but... - -- | of course. it may not be appropriate for someone paid by "X" | to be posting or the source of the comments | | [...] | | On Fri, Sep 28, 2001 at 05:46:56PM -0700, Sean M. Doran wrote: | > can i quote these two paragraphs please, anonymously or otherwise? | > or encourage you to post them? | > | > they are an important dose of factual information | > | > Sean. | > | > ps - bad cold, hence in for the night bored | > - -- | > | if people would just announce their /16's, /20's or aggregates | > | as well as the specifics it would solve the problem. people don't | > | understand their allocations then complain to us. | > | | > | the obvious case of that is when people get a /20 then | > | split the /24's into different geographic regions. as long as | > | they have a sensible policy, the rir will assign them /20's for | > | each location.

3 2

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

| Other providers never adopted filters, Sprint has since dropped its | filters. The Internet is still growing. Verio adopted filters. It is Verio's use of these filters which triggered tonight's whine-fest. | It even continued to grow faster because Sprint couldn't control its | own route announcements. You are confusing exponential post-filter growth of the global routing table (for which there is negative evidence) with exponential post-filter exponential growth of the number of things reachable through the Internet. I will not claim a causal relationship. However, it'd be nice if there were evidence that the constrained growth the first of enabled or at least increased the growth of the other, since that was the entire goal in the first place. | Its difficult to view the act as altruistic, when in the face of | impending doom, Sprint could always afford new routers, had deployed many, and was in the process of a defensive upgrade which would have meant the problem would never have occurred in the first place. Doom was never going to happen all at once, except to regional/national networks that did not/could not upgrade their routers in time. However, as noted by others, unconstrained growth would have made the Internet impossibly expensive to remain as dynamic as it was then and is today. | But perhaps we didn't recognize the behavior as a cry | for help. Well, you were either stupid or blind. | Much like and addict, it couldn't stop itself from prostituting "prostituting" | Many a politician and religious leader has condemned the | sinner, only to be found in bed with the sinner themselves. "sinner" by implication philanderer | A hypocritic condemns others for what he does himself. I call people names too, but my chosen epithets are both on-target and deserved. Sean. PS: | If you really believed the Internet was facing immenient doom, why | not also save it by also filtering the outbound announcements. Why | engage in the very behaivor your condemnded? This was answered at least twice earlier tonight. Blind or stupid? You tell me.

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

| So your downstreams pay you to connect to: | | + Your AS only; | | + Some of the Internet, but with little concern re accessibility | of small networks; | | + The whole Internet with as much reliability as possible? if #3 then what's the problem with: ip as-path access-list 1 permit _badguy_ route-map fix-badguy permit 10 descr proxy-aggregate the networks who are "holey" match as-path 1 router bgp my-as aggregate-address bad.guy.blo.ck1 255.255.224.0 as-set suppress-map fix-badguy aggregate-address bad.guy.blo.ck2 255.255.224.0 as-set suppress-map fix-badguy ... except that historically (with one exception, which was rude but educational) the "badguys" weren't really bad as much as lost somewhere, and didn't realize what was happening to them. So, rather than make a subtle change that some backwards ISPs never even noticed, a more forceful change (filtering) was made, and everyone noticed that, but more because of the continuing bad PR about how evil and rapacious it was to filter in the first place. Oh, wait, throwing away the holes can lead to a sub-optimal path selection! And troubles with holes coming from other directions! "shut up and send me a cheque." -> something more polite but meaning the same so that customer will happily pay for a "route-pull". Again, the great regret was the lack of a web page that would let one pay to blow holes in the filter and similar mechanisms that have been deployed from time to time (proxy-aggregation against backwards ISP, filtering against backwards ICM, RIPE-210 against the entire universe). | Maybe I'll filter anything longer than a /8... Please do, and tell us what you CAN'T reach after you throw away all the longer prefixes, and if you care after you install a default or proxy-aggregate, or whatnot to try to retain connectivity to those "extraneous info" destinations. Sean. ps - for those who don't know, ICM is AS 1800, and has an interesting history

2 1