Re: [IPFIX] 'not only IP Flows'

Hi all,

As long as the focus is on monitoring IP flows, I see no problem with the
name if we use IPFIX also for non-IP flows.

Thanks,
    Juergen

On 27.02.12 07:52, "Brian Trammell" <[email protected]> wrote:

>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

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