Dear all,

Thinking some more about this one.
It seems that there is an agreement for changing "IP packets" to 
"packets" in the definition

Let me summarize the options. The first three come from Brian's proposal 
below
1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers 
everything you might want to represent with IPFIX
4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or 
Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications
5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow 
or Flow", and from "IP packets" to "packets" when RFC5101 will go from 
Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to 
http://tools.ietf.org/html/rfc5472
     -> expressing that it's used also for non IP packets, among other 
things.
     -> it's good, but I don't think this solution is complete. For 
example, the ITU-T would still see the definition as being IP...


I'm in favor of 5. and 6., even though 4 would solve the problem now.

Feedback?
Do we want to discuss this in Beijing?

Regards, Benoit.

>  Brian,
>> Benoit, Gerhard, all,
>>
>> I agree with Gerhard here; call it a packet, leave the definition of 
>> packet ambiguous, so that it applies to any commonly accepted 
>> definition thereof.
>>
>> However, we have two separate problems here. The _other_ problem is 
>> how to handle the expansion of IPFIX as a generic flexible data 
>> representation into areas which are not directly related to flow 
>> measurement as originally envisioned. The prototype here is SIPCLF.
>>
>> As I see it, this problem should be solved separately from the 
>> problem of redefining flows for non-IP monitoring, and there are 
>> three separate general solution areas:
>>
>> 1. Do nothing, keep the (slightly expanded) definition of Flow. Here, 
>> we limit the applicibility of IPFIX to network management area, and 
>> exploit the fact that basically everything in the network management 
>> area is at the base of it going to involve packets going from 
>> somewhere to somewhere. In this case, every record represented using 
>> IPFIX is going to _somehow_ have a relationship back to _some_ set of 
>> packets which can be wedged into the present definition (the "packet 
>> treatment" clause in the 5101 definition affords us significant 
>> flexibility here). This works for SIPCLF as presently defined. 
>> Non-flow information can still be exported using Options, so it works 
>> for expanding IPFIX to decidedly non-flow things (e.g., physical 
>> monitoring scenarios, think periodic temperature reporting) as well, 
>> as long as all of these records can be represented as scoped to 
>> something (which I believe they can). In this case, we would probably 
>> want to mention this in the soon-forthcoming I
> E-Doctors draft.
>>
>> 2. Define a new category of data records which IPFIX can be used to 
>> export. These non-flow records would be represented as flow records 
>> (i.e., not Options), and would be equivalent to Flow records, except 
>> that the flow-specific provisions (uniqueness of flow keys, 
>> reversibility of non-key fields, etc., etc.) would not apply. The way 
>> to do this would be, I think, with another RFC which would present 
>> the expanded definition, and devices exporting/handling this non-flow 
>> data would therefore state compliance with this _new_ RFC. I'm not a 
>> big fan of this, personally, because it seems a little complicated, 
>> but it does allow us to segregate IPFIX-for-flow and 
>> IPFIX-for-not-really-flow better than (1) above.
>>
>> 3. Drastically expand the definition of Flow so that it covers 
>> everything you might want to represent with IPFIX. This strikes me as 
>> though it would take a great deal of effort, and break a lot of 
>> assumptions, basically as noted by Gerhard below. I mention it here 
>> only for completeness.
>>
>> My preference would be (1) (do nothing, note applicability). Thoughts?
> Right, as briefly discussed in the past, we would need an 
> applicability  version 2
>
> Regards, Benoit.
>> Best regards,
>>
>> Brian
>>
>> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote:
>>
>>> Benoit,
>>>
>>> I agree: "IP packet" can be replace by "packet".
>>>
>>> However, replacing "packet" by something like "packet, frame, or 
>>> cell" would probably cause inconsistencies in this and other 
>>> IPFIX/PSAMP documents. So, I would not go that far.
>>>
>>> Regards,
>>> Gerhard
>>>
>>>
>>> On 03.09.2010 12:20, Benoit Claise wrote:
>>>>   Dear all,
>>>>
>>>> Here is one problem that was anticipated...
>>>>
>>>> For whatever reasons at that point in time, RFC 5101 limits the Flow
>>>> definition to IP packets
>>>>
>>>>     IP Traffic Flow or Flow
>>>>
>>>>        There are several definitions of the term 'flow' being used 
>>>> by the
>>>>        Internet community.  Within the context of IPFIX we use the
>>>>        following definition:
>>>>
>>>>        A Flow is defined as a set of IP packets passing an Observation
>>>>        Point in the network during a certain time interval.  All 
>>>> packets
>>>>        belonging to a particular Flow have a set of common properties.
>>>>        Each property is defined as the result of applying a 
>>>> function to
>>>>        the values of:
>>>>
>>>>           1. one or more packet header fields (e.g., destination IP
>>>>              address), transport header fields (e.g., destination port
>>>>              number), or application header fields (e.g., RTP header
>>>>              fields [RFC3550<http://tools.ietf.org/html/rfc3550>]).
>>>>
>>>>           2. one or more characteristics of the packet itself (e.g.,
>>>>              number of MPLS labels, etc...).
>>>>
>>>>           3. one or more of fields derived from packet treatment 
>>>> (e.g.,
>>>>              next hop IP address, the output interface, etc...).
>>>>
>>>>        A packet is defined as belonging to a Flow if it completely
>>>>        satisfies all the defined properties of the Flow.
>>>>
>>>>        This definition covers the range from a Flow containing all
>>>>        packets observed at a network interface to a Flow consisting of
>>>>        just a single packet between two applications.  It includes
>>>>        packets selected by a sampling mechanism.
>>>>
>>>> However, we know that IPFIX cover more than IP.
>>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions
>>>> sourceMacAddress, ethernetPayloadLength, etc...
>>>> And we know that IPFIX became a kind of generic streaming protocol.
>>>>
>>>> Talking in the context of the NGN networks at the ITU, there are some
>>>> reluctance to adopt this Flow definition limited to IP packets.
>>>> Isn't it time to do something about this definition?
>>>>
>>>> Regards, Benoit.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix