May 2000 - Test - lists.nanog.org

Re: CIDR Report
by Danny McPherson 15 May '00

15 May '00

> None of these are big enough to justify their own backbone operations or to > buy a backbone from someone else, or there wouldn't be a problem. Paying scads > of extortion money is also problematic (cheaper to simply burn the IP addresses). > > I am NOT advocating tossing all of that out. I am simply bringing up a > problem condition. Please, don't shoot the messenger, or otherwise get > defensive (return fire is a bitch). Nope, all of these are reasonable, the ones that aren't are, for example, where folks have a single connection, or multi-home only to a single provider. > What I am bringing up here is that new, information-age companies, > as predicted in MegaTrends over 10 years ago, are now starting to > appear. They are very diffused (sparse population, over very large > areas of the globe) and have connectivity needs which are both critical, > yet very different from click-n-morter customers that the Big8 was > built up to handle (either classful or classless). The current architecture > is not handeling them very well. > > The problem is currently in it's infancy, it will get much worse. I'm not disagreeing with any of this. Actually, I see reliability and availability feeding into all these other issues as well. It just that some of the folks advocating portability and deaggregation are using "route table size doesn't matter anymore" as an argument, when it absolutely does matter, especially if we plan to make the Internet more reliable, and less vulnerable. -danny

7 8

Re: ATOMIC AGGREGATE
by Danny McPherson 15 May '00

15 May '00

> I am trying to understand the BGP ATOMIC AGGREGATE attribute from a BGP > router which receives aggregate routes. Can somebody tell me what is the > action > taken by a BGP router when it receives a aggregate route with ATOMIC > AGGREGATE. > > I understand that the ATOMIC AGGREGATE is used when there is loss of > information while aggregating the routes. But what does the receiver of > the attribute do with the information. what kind of action does it take > ? It serves as an indication to the receiver that it can't "deaggregate" the prefix per some of the granularity associated with the NLRI of that route (i.e. AS paths) may have been lost when the aggregate was created, and deaggregation could result in the introduction of loops. > If anyone can put some light on how this BGP attribute gets utilized in > the real world i would greatly appreciate. However, I don't believe many folks actually deaggregate routes in real networks (at least not intentionally :-). I've seen several implementations which don't correctly attach the attribute, though it didn't break anything at the time. In the future, queuries of this nature may be more appropriately directed to the IDR WG list (bgp(a)ans.net) -danny

1 0

[Fwd: Re: Optical Crossconnects and IP]
by Andrew Bender 15 May '00

15 May '00

Vadim Antonov wrote: > I would like to inject some sanity into the traffic engineering > discussion by reminding about some small fact of life: > > Nobody knows how to measure how what the demanded/available bandwidth > ratio is when the circuit is overloaded. I think the point of TE is to avoid overbooking in the first place, and also calculate a suitably assured protection path. (or just build for the busy hour, of course) > What it means that by and large traffic engineering is done by seat of > the pants. May be so, but at some point every business will be accountable to operating cost. This is the hallmark of a mature sector in a commodity market, in fact. > PPS Pluris core technology allows to treat traffic as a liquid - unlike simple > IP routing it works by splitting aggregated streams, which can be sent > along different paths. Not by hashing flows I hope. Otherwise, I suspect that non-Newtonian CFD per macroflow can't possibly be a time-complexity win over the "simple" MCF optimization problem... :P Regards, Andrew Bender thrupoint.net

1 0

NANOG 19
by Carol Wadsworth 15 May '00

15 May '00

Registration for NANOG 19 is now closed. A waiting list has been established. If you would like to add your name to the list, please send email to carolw(a)merit.edu and include your organization and telephone number in the message. Thanks. Carol Wadsworth Merit Network, Inc.

1 0

ATOMIC AGGREGATE
by Phani Koganti 15 May '00

15 May '00

Hello, I am trying to understand the BGP ATOMIC AGGREGATE attribute from a BGP router which receives aggregate routes. Can somebody tell me what is the action taken by a BGP router when it receives a aggregate route with ATOMIC AGGREGATE. I understand that the ATOMIC AGGREGATE is used when there is loss of information while aggregating the routes. But what does the receiver of the attribute do with the information. what kind of action does it take ? If anyone can put some light on how this BGP attribute gets utilized in the real world i would greatly appreciate. Thanks in advance. Regards, Phanidhar Koganti.

1 0

Re: Please Format Your Posts
by Martin Cooper 15 May '00

15 May '00

Sean Doran <smd(a)clock.org> writes: > I know that I am old & curmudgeonly now, but surely I cannot > be the only NANOG person who uses UCB Mail on occasion? I don't even use an MUA... ;-) $ cp /var/mail/mjc64 temp $ vi temp $ /usr/lib/sendmail -t < temp > Sean. (who could buy a fancy email system, > but doesn't want one at home > and who could buy a big-iron router, > but doesn't want one at home) Martin (who doesn't want a computer at home -- I spend enough time in front of them at work thanks...) M.

1 0

Please Format Your Posts
by smd＠clock.org 15 May '00

15 May '00

I know that I am old & curmudgeonly now, but surely I cannot be the only NANOG person who uses UCB Mail on occasion? Or is it a lost cause to expect people to be concerned about the number of characters on a line, when they are arguing that we shouldn't worry about the number of globally-known routing prefixes? Sean. (who could buy a fancy email system, but doesn't want one at home and who could buy a big-iron router, but doesn't want one at home)

11 10

Re: CIDR Report
by Steven M. Bellovin 15 May '00

15 May '00

In message <003301bfbd8b$ae6f5960$eaaf6cc7@PEREGRIN>, "Roeland M.J. Meyer" writ es: > >> Owen DeLong: Saturday, May 13, 2000 3:35 PM >> >> > I actually agree with you here as well. relying on infinite >> router table growth is not a scalable strategy. We need >> something else. >> > >> Just a small technicality here, noone is talking about >> infinite routing >> table growth. There are only 4 billion (roughly) possible prefixes >> if you route every node as a /32. While 4 billion is a large number, >> it is far from infinity. > >Well, that statement was obviously not intended literally. But, since we're >throwing around numbers ... > >Simply taking addresses only, that comes out to ~16GB. At $100 per 64MB >this is about $25,000.00US in RAM, at current retail rates (prices may >vary by vendor). It's also about $16,000.00US of EMC disk-space. This >means that one full table would cost about $41KUS, just to store it. >But, what will this do to performance of such a router that's working >in a gig-E environment? The index table to access this puppy would be >larger than the prefix table. This could easily double the cost, say $82KUS? >Considering that I just paid $98KUS for a Cisco Catalyst 6509, I guess >this isn't too bad. However, this is only IPv4 and it is a bunch more than >the cost of the average BGP-capable router and every router on the backbone >would have to be upgraded. This is conservative since I have not yet allowed >for memory structure overhead. However, code-space would be relatively trivial >, >even Microsoft wouldn't be able to bloat it enough so anyone else would notice >. Of course, note that the real problem isn't the memory space, it's the CPU time to calculate the routing table updates. Note, too, that the more unaggregated prefixes in the net, the more changes will need to be propagated to every other router in the default-free zone, implying the need for more instances of a more expensive calculation. --Steve Bellovin

2 1

CIDR Report
by pjnesser＠Nesser.COM 15 May '00

15 May '00

I was just looking through the graphs on Tony's Web site and noticed something somewhat disturbing. For the first 2000 days of Tony's plots (starting from 1/1/1994) the number of routes has grown roughly by 10,000 every 500 days. so 20k --> 30k, 30k --> 40k, 40k --> 50k, & 50k --> 60k. But if you look at the last 250 days or so you see that the table has grown by more than 16k routes. So we are seeing growth at 300% of what we saw for the last 5 plus years. It also looks annoyingly geometric or perhaps exponential, instead of the nice linear growth since CIDR was introduced. Take a look at: http://www.employees.org/~tbates/cidr.hist.plot.html Just eyeballing it since I am too tired to actually plot the number right now it looks like we could hit 100k routes by the end of the year or early next year. To the $64,000^h^h^h^h^h^h $10,000,000 (you gotta change with the times :-) questions are why? anyone care to guess when it starts to become a problem and with what widely deployed boxes first? is there anything we can do about it? Have a good weekend. ---> Phil

10 9

Re: Multi-home II
by Rural CNE 15 May '00

15 May '00

> While I have no idea what "e-Internet" (Even telephony network has > been Electric since several decades ago. Or do you mean RFC1149 > and RFC2549?) and "IAP" (sounds like a NAT based anti-ISP which > certainly has no reason to multi-home) means... The "e-" prefix was borrowed from the trade press. The current trend is to attach the "e" and claim that their hardware/software solution will enable you to conduct "eBusiness" through the use of "eCommerce." "IAP," or Internet Access Provider, was an acronym taken from nanog's website and refers to small / medium size ISP's. > draft-ohta-e2e-multihoming-00.txt I will check it out. -brad (Rural CNE) bwalters(a)inet-direct.com

2 1