On Tue, Mar 19, 2013 at 1:57 PM, Jared Mauch <ja...@puck.nether.net> wrote: > > On Mar 19, 2013, at 1:50 PM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > >> On Tue, Mar 19, 2013 at 1:45 PM, David Conrad <d...@virtualized.org> wrote: >>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow <morrowc.li...@gmail.com> >>> wrote: >>>> There's nothing inherent in BGP that would not work with an >>>> unconstrained growth of the routing table, right? You just need enough >>>> bandwidth and interrupts to deal with updates. >>> >>> With enough thrust, pigs fly quite well. Landing can get messy though... >> >> I was being serious... the current 'bgp unconstrained dies' problem >> isn't such a problem if you have (today): >> 4-8 cores >> 16 gb ram >> ssd >> gigabit ethernet >> >> or as you'd call this, your desktop computer... trying to do this on a >> 600mhz mips with 512mb ram is, clearly, a problem. put modern >> hardware to work and it gets simpler. Yes, the above addresses >> getting/sending 'rib' data, it doesn't address programming a FIB, but >> rethinking the programming of the fib a bit could, I bet, even get us >> to a palatable point for a longer while, in a relatively short period >> of time. > > Try telling this to a vendor that uses these common components (eg: Juniper)
you mean a vendor embeded in their current design? ok. > We have had numerous performance issues that have been attributed to software > defects they haven't observed on their 'modern' hardware, but is visible in > the prior generation or few back of routing engines. > > There's also the problem of fitting the data in the appropriate SRAM on a > linecard which is very expensive on a per-bit basis to purchase and on a > per-watt basis to operate. This is why some folks have TCAM based platforms, > which have their own tradeoffs. > right, these are design choices they made ~10 years ago and didn't upgrade along with the problem space. I'm really saying that we almost have to take a fresh slate look at the problem... 'if you could do things again, without the constraints of what we have today' > We all can't just forward with N*10GE interfaces in a x86_64 platform. That > may work if your scale is small, but when you're quite large the dynamics > change considerably. > sure thing. > Also, a "modern router" might look like this: > > cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of > memory. > Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174 > > vs > > Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of > memory. > Processor board ID 23671962 > SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache > > > Those that are confusing the two need to be sent to reeducation camp :) yes, still all single threaded and single core and ... :( 32bit, woot :( so constrained to some extent on max-memory and address space. also, I don't think this is 'just that simple'... but the tools exist.
