- NANOG - lists.nanog.org

The real problem
by Scott Huddle 02 Mar '97

02 Mar '97

Mike, If I follow your observation, routing computation growth is non-linearly related to number of routes. Or is it orthogonal? If the growth is related to the announcement, this infers that costs incurred for the announcement of routes by ISP FOO to ISP BAR would be non-linear with the quantity, correct? If those costs are non-zero, then BAR needs to be compensated by FOO for the announcement. One way for BAR to recoup its costs would be for it to collect a payment from FOO. Thus FOO "buys" a routing slot from BAR. From your observation, these payments may be non-linear related to quantity. Note that BAR may owe a similar payment to FOO for consumption of the same resources on FOO's network. Without the payments you have market failure -- consumption of the resource is unchecked ("tragedy of the commons") and people who "want" or "need" to make a route announcement, and who *could pay* for the resources that they consume, cannot do so. Thus the REAL problem is that we don't have markets for the determination and allocation of these scarce resources whether you call them "routing slots" or "routing complexity". Redirected to piara. -scott At 12:09 PM 3/2/97 -0500, Mike O'Dell wrote: > >Yet again people keep talking about "the size of the routing tables" >as being the deep problem, and this makes people say silly things >like "FOO is protecting router memory". > >Thinking about it this way is funamentally and fatally incorrect. > >The REAL problem is the growing complexity of the ROUTING COMPUTATION, >not the size of the resulting forwarding table. even if routers >had infinite memory, we would still be crushed by the routing >computation if allowed to grow unchecked. > > -mo > >

1 0

more to add to the list
by Sarah Noelle Pratt Ferguson 02 Mar '97

02 Mar '97

Greetings. My apologies, I don't know if this is appropriate or not. I read vix.com/spam, and didn't see how to report rogue sites. I've gotten spam from worldnet.att.com four times in the last four days. I've received no response from postmaster, and any mail I send back to the site says that the mailbox is full, so the message won't be delivered. So, in future, how do I report a rogue site? Should I simply mail scott mueller? Have fun. -s- > FOR INFORMATION ON BULLETPROOF, RENEGADE, > RESULT ORIENTED MASS ADVERTISING > CONTACT MREMAIL AT 714-825-4815

2 1

Re: The Big Squeeze
by Paul Ferguson 02 Mar '97

02 Mar '97

At 10:48 AM 3/2/97 -0500, Jim Jagielski wrote: > >It's the renumbering part that I think gives people the most >heartburn... By the time you get "big enough" to warrent your >own block, you've got at least 32 ClassCs of which, I'm betting, >at least 28 are "given" to LAN-connected customers. This is >a _major_ headache not only for the ISP to go thru but also a >major headache to force your customers to go thru. That is, what >I think, is what really is most painful; that by the time you >are big enough to have your own block, you're too big to want >to renumber: Catch 22 > Que sera, sera. Renumbering is a fact of life. See: RFC1900, RFC2008, RFC2071. - paul

4 3

Re: "routing table slots" and the real problem
by Paul Ferguson 02 Mar '97

02 Mar '97

At 01:33 PM 3/2/97 -0500, Scott Bradner wrote: > >Mike says >-- >The REAL problem is the growing complexity of the ROUTING COMPUTATION, >not the size of the resulting forwarding table. even if routers >had infinite memory, we would still be crushed by the routing >computation if allowed to grow unchecked. >-- > >and the frequency at which the computation must be done > >Scott > Ah, yes. Absolutely. - paul

1 0

Re: "routing table slots" and the real problem
by Scott Bradner 02 Mar '97

02 Mar '97

Mike says -- The REAL problem is the growing complexity of the ROUTING COMPUTATION, not the size of the resulting forwarding table. even if routers had infinite memory, we would still be crushed by the routing computation if allowed to grow unchecked. -- and the frequency at which the computation must be done Scott

1 0

Re: "routing table slots" and the real problem
by Paul Ferguson 02 Mar '97

02 Mar '97

At 12:09 PM 3/2/97 -0500, Mike O'Dell wrote: > >The REAL problem is the growing complexity of the ROUTING COMPUTATION, >not the size of the resulting forwarding table. even if routers >had infinite memory, we would still be crushed by the routing >computation if allowed to grow unchecked. > I have always subscribed to this fundamental concept; memory to accommodate N number of routes has never been an operational issue. As you have stated, it's the computational resources required to calculate optimal paths when path information changes. There is a linear relationship between the number of paths & routes that must be parsed, and the amount of time it takes to compute install the best one(s). - paul

1 0

Re: The Big Squeeze
by Paul Ferguson 02 Mar '97

02 Mar '97

At 11:33 AM 3/2/97 -0500, Jim Jagielski wrote: >> >> Que sera, sera. Renumbering is a fact of life. >> >> See: RFC1900, RFC2008, RFC2071. >> > >Never said it wasn't a fact a life, just that it's a painful >one... And a disruptive one. Imagine the heartburn if a group with >simply one ClassB was required to totally renumber to another... > I never meant to imply that it wasn't disliked and painful. One also might suggest that address portability is very much dependent on the prefix size and it's ability to aggregated (or not) elsewhere in the global topology. Having said that, a /16 is generally considered portable. - paul

1 0

Re: The Big Squeeze
by Paul Ferguson 02 Mar '97

02 Mar '97

At 08:14 AM 3/2/97 PST, Randy Bush wrote: >User-defined paradigm shifts. I bet that is what the Loony Sociopaths for >Demagoguery (acronym intended) are trying to achieve on a number of these >lists. I suspect it may require more experienced and rational users. One >shifts paradgms with experience and consensus, not volume. > 'Rational' being the operative word here. ;-) - paul

1 0

Re: The Big Squeeze
by Paul Ferguson 02 Mar '97

02 Mar '97

At 07:51 AM 3/2/97 PST, Randy Bush wrote: > >If the ops are heading toward the above-described convention, would it not >be cool if the router vendors made it the default? > Paradigm shifts can happen anytime. Best to make it user-definable. :-) - paul

2 1

Re: The Big Squeeze
by Paul Ferguson 02 Mar '97

02 Mar '97

At 07:36 AM 3/2/97 PST, Randy Bush wrote: >> I would suggest that the largest percentage of flapping prefixes in the >> global routing system belong to prefixes longer than /19. > >Hence the convention to damp differently for different lengths. See one of >the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we >over here start following the European lead on this. > Also, the dampening defaults: bgp dampening <halflife-time> <reuse> <suppress> <maximum-suppress-time> <halflife-time> default is 15 minutes <reuse-value> default is 750 <suppress-value> default is 2000 (I thought it was 1000, but docs indicate otherwise) <max-suppress-time> default 4 times halflife-time - paul

2 1