Re: [IPFIX] 'not only IP Flows'

Hi, Nevil, all, 

In the current working copy of the -bis drafts, "IP" has been dropped as a condition of the definition of "Flow". Again, I think this is not so much proscriptive as merely a reflection of reality. We could consider a "historical note" about the name of the protocol if we want to make that more explicit.

Cheers,

Brian

On Feb 26, 2012, at 8:15 PM, Nevil Brownlee wrote:

> 
> Hi all:
> 
> At this stage IPFIX is out there and being used - it's certainly too late
> to change the name (even to EIEIO!).
> 
> However, I like Paul's answer to the 'why have IP in the name?' question -
> it really is a protocol for exporting information *over* IP, using SCTP,
> TCP or UDP for transport.
> 
> Maybe that notion needs to get into our *bis* drafts ?
> 
> Cheers, Nevil
> 
> 
> On 02/24/2012 01:24 PM, Brian Trammell wrote:
>> 
>> On Feb 24, 2012, at 9:33 PM, Christopher White wrote:
>> 
>>> 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.
>> 
>> I wouldn't call this "way beyond" where IPFIX is now. Have a look at draft-ietf-ipfix-ie-doctors, which specifies (in section 8) how to "design" new applications for IPFIX which are not strictly-speaking Flow based.
>> 
>> All of the examples above pretty much apply to the "notional Flow" approach outlined there.
>> 
>>> 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.
>> 
>> If you've designed your templates correctly (i.e., such that each template or group of templates really does represent a separate data type), the type of a record can be very easily deduced at the collector side based on the presence of a set of Information Elements (and perhaps the absence of a different set of Information Elements) in the template, allowing you to keep a SetID/type map. See draft-trammell-ipfix-sip-msg for an _explicit_ example of how to do this. I'd recommend against defining a "type" information element, as you can run into some pretty silly inconsistencies.
>> 
>> (6313 as published breaks the ability to determine type from the template in the general case; see my slides on this in Taipei for more, so for applications where data typing is important, either don't use 6313 or come help us design a fix :) )
>> 
>> Cheers,
>> 
>> Brian
>> 
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
> 
> 
> -- 
> ---------------------------------------------------------------------
> Nevil Brownlee                    Computer Science Department | ITS
> Phone: +64 9 373 7599 x88941             The University of Auckland
> FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> 
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix