Re: OMB: IPv6 by June 2008
No one real DOS attack can create traffic, sugnificant for core routers (except one - two worm cases when millions of computers generated random traffic). I do not see a problem there. All problems you are talking about are resolved in modern CPU industry, resolved in modern servers, Router vendors just never had such task. Notice, that modern routers are MORE THEN anough for modern Internet. If routing tables grouth 10 times, routers will follow this trend without sugnificant difficulties. IPv6 looks exactly as ASN.1 - when Telco created it many years ago, they attempted to pack everything into very slow 9600 bandwidth. Result - when you see it in H.323 today, running on 100Mbit links, it's all unnecessary (and it explains why SIP substitutes H.323, even if it never used excellent ASN.1 packing schema /do not bite me, there are many other reasons, of course/). The same here. Many many years ago it looks as CIDR is 100% required and as MH can not be achieved for small companies and that we must limit Internet size to 100,000 routes. Today, we have much more, and do not foresee any problem related to route table sizes. I am not saying that Ipv4 mh approach is excellent, but I do not see anyone, who proved that it could not work in future networks, instead of twisty and tricky IPv6 addressing schema without MH at all. (Of course, it all will result in the same trick - every smalll entity in IPv6 will have it's own PI address block, no one idiot will be able to live with constant renumbering they proposed to use. Just wait 2 - 10 years and you will see). ----- Original Message ----- From: "Dave Andersen" <dga@cs.cmu.edu> To: "Alexei Roudnev" <alex@relcom.net>; "Syed Junaid Farooqi" <syedjunaid@hotpop.com>; "Christopher L. Morrow" <christopher.morrow@mci.com> Cc: "NANOG" <nanog@merit.edu>; "Brad Knowles" <brad@stop.mail-abuse.org> Sent: Saturday, July 09, 2005 11:34 AM Subject: Re: OMB: IPv6 by June 2008
A cache-based architecture of the sort you describe is prone to thrashing under weird traffic patterns (such as those introduced by DoS attacks...). There's something to be said for having routers that can forward at or near line-rate regardless of the traffic patterns, packet sizes, etc. If you're holding 1% of your routing table in core, and it takes you several packet transmissions worth of time to go off-card to fetch different routing entries, you have a pretty serious problem.
Thankfully, nobody ever tries to scan the entire 'net, causing major thrashing in lookup tables. [...]
Also, keep in mind that memory is either big and cheap -- in which case you're creating a size problem for routers that already take up enormous amounts of space -- or small, fast, and very expensive. Memory, particularly static ram, is also a power hog. Todays BFRs dissipate about as much power as my electric stove on full blast.
If there are architectural solutions that can reduce the cost, size, and power consumption of routers while simultaneously providing improved availability, it seems silly to ignore them.
-d
----- Original Message ----- From: Alexei Roudnev To: Syed Junaid Farooqi ; Christopher L. Morrow Cc: NANOG ; Brad Knowles Sent: Saturday, July 09, 2005 1:42 PM Subject: Re: OMB: IPv6 by June 2008
LC can hold only 20,000 ACTIVE routes., and ask central system if it needs more., How many ACTIVE routes are used in any CORE router? 0.1% or CORE? 2% of CORE?
Again, today it is not technical issue anymore. ----- Original Message ----- From: Syed Junaid Farooqi To: Christopher L. Morrow Cc: Alexei Roudnev ; NANOG ; Brad Knowles Sent: Saturday, July 09, 2005 1:02 AM Subject: Re: OMB: IPv6 by June 2008
Christopher L. Morrow wrote: randy already asked for a kibosh on the lunacy here... I agree, it'd be nice, but...
On Fri, 8 Jul 2005, Alexei Roudnev wrote:
You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms.
and routing vendor's haven't already done some optomizing you think?
They sure have, let me explain a bit - Optimization here can be is Route table optimization, forwarding table optimization and the actual forwarding lookup paradigm. But having the best and most opitmized algorithm makes no difference if there is not enough memory on the Line Card, having said that - 1G to 2G mem is something that is already supported by a few vendors - on the Line cards and 2G and above on the Processors (route processor..?)
On the other hand - what's wrong with 4Gb on line card in big core router?
oh, please please name the router vendor that has 4gb of 'ram' (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one? One wonders why that is? If the solution were as simple as: "Joe, add 1.21jigawatts of memory to the linecard so we can support +1M routes" Don't you think the vendor would have done this to get people to stop bitching at them?
Now, now, The RAM mentioned in terms of Gb should not be thought, even inadvertently, to have something to do with TCAM/fpga/asic - Memory here can be divided in to 1. forwarding memory , 2. Line card CPU memory, 3. TCAM memory (damn costly stuff )
And as for the number of routes to be support -Right now venodrs do support close to 500K routes - ask me to name the vendor (notice i did not say Vendors here) and i will be happy to name.But, yes to do something like 1M routes - ahem mighty tricky stuff aint it, but, does any one have 1M active routes in his table as of today (notice how iam trying to evade commenting ;) you cant haul me for saying this)
It's cheap enough, even today. And we have not 1,000,000 routes yet.
In YOUR network you don't... I'd venture to guess there are quite a few very large networks with +1M routes in them today.
remember though, I'm the chemical engineer... and I was trained to MAKE the crack cocaine...
1M routes, BGP is hope so - and not on a single box i suppose so. come on, 1M + active routes- it sure would be a killing on the box.
Chemical engineer you say, what a wonderfull world - Iam a pharmacist- fully trained to give an anitdote to cocaine addicts.
CIAO
participants (1)
-
Alexei Roudnev