[j-nsp] TCAM full on EX8200?

[Jeff Wheeler]

On Sat, Oct 15, 2011 at 6:04 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> ...whereas because ACLs are variable length, determined by customers and
> possibly large, performance of a RAM-based ACL algorithm is hard to predict,
> and people want predictable performance, and usually line-rate performance.

It's not so much that it's hard to predict -- it isn't.  It's hard to
market.  Customers can't understand that the 100 line ACL in front of
their server farm is spending too much time walking a structure (or
executing instructions) read from RAM.  They can understand if the
vendor says "wire speed" and that's what is marketable.  The trade-off
is flexibility, which you mention below...

> Having said that - personally I might be willing to trade line-rate
> performance for (say) an ACL mechanism with near line-rate for simple ACLs,
> the option of a "jump" opcode, and some way of knowing what the exact
> performance (range) of a given ACL/interface combo would be.

Most customers find that their Juniper boxes still operate at wire
rate even when they load up some ugly filters.  On some boxes in some
cases, however, that is not true.  But to generalize, M/MX does
everything with RAM, provides the operator with more flexibility, but
also gives him a little more rope with which to hang himself.

> Do I take it that non-destination-based routing (policy routing, filter
> based forwarding) are therefore implemented differently on boxes that use
> RAM-based forwarding?

"There's more than one way to do it," but to use M/MX as an example
again, this still happens using RAM.  In a box designed for routing
tables (or MAC/ARP/MPLS/etc) the size of what M/MX delivers, CAM is
not the most effective solution.  Could they glue some on for the
purpose of accelerating large ACLs?  It depends on the match terms.
CAM still cannot implement the fancy operations you can do with
Juniper firewall filters in one operation; all it can potentially do
is accelerate the types of filters that optimize better into TCAM
matches than ALU+RAM searches.

I doubt Juniper has ignored the possibility of grafting some CAM onto
their "router" boxes for certain operations, but when you already have
the ALU+RAM method R&D'd and you can simply scale it up a little bit,
this is probably more sensible than adding a power-hungry CAM and all
the guts necessary to interface to it, and then do more R&D to have
the control-plane figure out how to take advantage of it, and *then*
still live with the fact that Juniper firewall filters *still* give
you the flexibility to make that operation not perform at wire rate
also.

> Hehe. "Tag switching will make core routers really cheap, you'll have a few
> really big PE routers only". Wasn't that the line we were sold with TDP?

I see Richard has covered this in his follow-up.  I'm sure you
eventually will get those cheap LSRs, but there is no reason for Cisco
or Juniper to be the first to market these devices.  Either one of
them could decide to spin up that product, glue it all together from
their existing technology, and ship it in no time; but why would they
when that would take away from big iron product segments?

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts