On 28 February 2016 at 22:06, Todd Crane <todd.crane@n5tech.com> wrote:
This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol)
I view sflow as subset of NetflowV9 V10/IPFIX. You could produce sflow behaviour in IPFIX, by adding record of packet sample, and exporting immediately instead of keeping state of flows. However you couldn't produce IPFIX behaviour in sflow, inherently so. sflow is older than IPFIX (v10) or v9 netflow, and I'm guessing no one would invent sflow today, they'd instead specify some restricted IPFIX with same behaviour. I completely understand why sflow was needed netflowv5 time, but I don't really see much point there now. It just means that collectors need to be more complicated than they must, by having two parsers. -- ++ytti