Re: [IPFIX] Flow in IPFIX -> not only IP Flows
Christopher White <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <F2ABE9FB3E054747B6FBB226A9A833890AC242AF@365EXCH-MBX-P1.nbttech.com> |
Hi Paul and Brian, > From: Paul Aitken [mailto:[email protected]] > > Honestly, I think the larger problem we have on this point is with the > > name of the protocol: with the IP right up front in the first two > > letters, it'll be hard to sell as a layer 2 measurement protocol. :) > > The existing IANA elements show that it can measure metrics at any layer. > Even "flow" isn't so relevant these days. > > So IPFIX isn't export _of_ IP, it's export _over_ IP. [Christopher White] Yes, I'm actually even thinking a bit more broadly as well, such as export of other statistics: * Per Interface utilization * Server stats (cpu/memory per process) * Queuing stats (queue len, loss) As such it may not even be IP or flow related, it's just a nice well defined mechanism for the regular export of statistics. I certainly understand this takes the scope of IPFIX way beyond where it is now, but I find it particularly intriguing, because once a product has support for export IP/flow based statistics via netflow, there's a lot of infrastructure already in place that one would like to reuse for exporting other non-IP/flow stats. It's all pretty much doable using the existing IPFIX language, if you simply allow for other records with different key fields. For flows, the key fields are based generally on the 5-tuple, and thus all flows are pretty much expected to have those or some subset. If you monitor some other class such as server stats, you simply need to define new fields and be able to flag which fields are the key fields (process / thread, for example). It seems this would merely require some common field across all flows to indicate what class of item this is. This might be indirectly discovered based on the fields in the flow (presence of IP src/dst indicates an IP flow, presence of process/thread is server stats), but such indirect logic is always problematic. ...cj _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix