i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts?
Isn't the reason that "NetFlow" (or v10 which is the the IETF/Cisco named IPFIX) exists the side-effect of having routers doing "flow based routing" aka "keeping an entry per IP flow, thus using that entry for every next packet to quickly select the outgoing interface instead of having to go through all the prefixes" ?
flow-cache based forwarding can work perfectly fine provided: - your flow table didn't overflow - you didn't need to invalidate large amounts of your table at once (e.g. next-hop change) this was the primary reason why Cisco went from 'fast-switch' to 'CEF' which uses a FIB. the problem back then was that when you had large amounts of invalidated flow-cache entries due to a next-hop change, typically that next-hop change was caused by something in the routing table - and then you had a problem because you wanted to use all your router CPU to recalculate the next-best paths yet you couldn't take advantage of any shortcut information, so you were dropping to a 'slow path' of forwarding. for a long long time now, Cisco platforms with netflow have primarily had netflow as an _accounting_ mechanism and generally not as the primary forwarding path. some platforms (e.g. cat6k) have retained a flow-cache that CAN be used to influence forwarding decisions, and that has been the basis for how things like NAT can be done in hardware (where per-flow state is necessary), but the primary forwarding mechanism even on that platform has been CEF in hardware since Supervisor-2 came out. no comment on the merits of the approach by Larry, anything i'd say would be through rose-coloured glasses anyway. cheers, lincoln. (work:ltd@cisco.com)