March 1997 - Test - lists.nanog.org

RE: The Big Squeeze
by Jim Fleming 02 Mar '97

02 Mar '97

On Sunday, March 02, 1997 4:15 AM, Nathan Stratton[SMTP:nathan@netrail.net] wrote: @ On Sun, 2 Mar 1997, Sean Donelan wrote: @ @ Number of routes, I know of 2 ISPs that we provided access to that were @ mad because the nic gave them /19 and not /18. The providers are now out @ of business and there are 2 /19 not being used, but at least they are not @ /18. If the provider did get larger the nic would have gladly taken back @ the /19 and given them a /18. @ If there were regional IP registries that had an economic incentive to reclaim those 2 /19s, then those would be recycled and reused. If you accept that people are going to fail, then you have to plan in advance for taking allocations back, or better yet, not renewing the lease. This happens in real estate with office space all the time. Many buildings do not fragment their space because they have a hard time leasing small spaces. Again, there are economic and market-based reasons for this. It would be nice if the same could be said for IP addresses. The ARIN discussions (http://www.arin.net) focus on some of these topics. -- Jim Fleming Unir Corporation e-mail: JimFleming(a)unety.net JimFleming(a)unety.s0.g0 (EDNS/IPv8)

2 1

Re: "routing table slots" and the real problem
by Vadim Antonov 02 Mar '97

02 Mar '97

>I have always subscribed to this fundamental concept; memory to >accommodate N number of routes has never been an operational >issue. Not the case with one vendor's boxes. Memory _was_ the issue after introducing CIDR. AGS/+s and early 7000s were running out of memory, not out of CPU cycles. --vadim This message is brought to you by the society for history preservation :)

2 1

"routing table slots" and the real problem
by mo＠UU.NET 02 Mar '97

02 Mar '97

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

4 3

Re: The Big Squeeze
by Scott Huddle 02 Mar '97

02 Mar '97

At 10:00 AM 3/2/97 -0500, Paul Ferguson wrote: >This is not to say that [ISPs] could be economical incentivized to >accept routes for arbitrarily long prefixes. I'll assert that if the costs of accepting a route announcement are non-zero that this can only happen if there is a market for announcements and a system of settlements between providers. If the costs are zero, then why have the filters? Redirected to piara. -scott

1 0

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