You need sFlow?
Please add sFlow support.
http://www.sflow.org/sFlowOverview.pdf
I know there is currently NetFlow/IPFIX support, but both protocols are very limiting when it comes to realtime monitoring or more importantly realtime acting on exported flows (ie: DDoS detection)
If you need do DDoS detection best is to put on top or behind a crs317 switch and setup port mirroring.
You can monitor mirrored traffic in real time.
Yes I know that. This solution does not scale at all.
It’s not easy nor cheap to mirror multiple 10gbit pipes from your edge to a central location for monitoring/management.
CRS317 is within 250 price range, not something unsustainable and you get 16 10gig port on dual power supply.
If you’re running multiple 10gig ports you have ccr1072. The only chance to absorb DDoS attack is keeping it on fast path. If you use fastrack or filter in raw you will see unfiltere package in slow path and your router will die with little attacks.
If you want deal DDoS keep border router on routing only (best one for every link) on fastpath and install additional devices for other applications.
What you say is not feasible economically and technically.
Think multiple routers with fiber uplinks in multiple racks, hence multiple CRS317s, multiple SFP modules, multiple NICs in the capture machine, plus lost Us in racks for all that.
Plus you then need a monster of a machine with specific NICs (if you hope to reach wirespeed) just to capture the data and process them. Total mess and totally not a scalable solution.
Not to mention the man-hours just to set up and maintain all this as your network (and routers/uplinks) gets bigger.
All these add up. It’s not just ‘250$’ (btw CRS317’s suggested price is 399$).
sFlow (or Netflow/IPFIX for that matter) makes monitoring much more economical and manageable. You’ve got tons of software to work with it and with just a VM (albeit a beefy one) on your already set up cloud infrastructure you can monitor your flows and act upon them. No need for extra hardware or man-hours.
I dunno, maybe it’s just me but I think most CFOs and CTOs would choose sFlow over what you propose 
+1 for sflow.
+1 for sflow
+1 sflow
+1 sflow!!
sFlow requires HW support (switchchip / dedicated ASIC). They clearly state it in their overview. It can’t be simply added with software update.
Not true.
There is a software implementation that works on Linux.
https://sflow.net/about.php
Sorry for digging out but please… add sFLOW
it’s much faster in DDoS detection than NetFlow (mikrotik’s Trafic Flow)
+1 sflow, almost in 10G cable routers
+1 for sflow.
+1 sflow
In the point of view of Hardware Offloading, sFlow is much lighter than NetFlow or IPFIX.
No complex tables to be feeded by information from forwarding, from FIB, and from RIB.
Just the crude and simple packet sample.
Please give us the possibility of choosing between IPFIX and sFlow.
Something like “Flow Sampling Profiles”.
That would allow:
sFlow bring low computing overload, and very fast delivery of packets to the collector/analyser.
IPFIX is very important to more elaborated things like Event-Based Logging for NAT, and others.
But beyound that, BMP + sFlow can give you anything IPFIX gives.