Re: [IPFIX] Flow in IPFIX -> not only IP Flows

Benoit Claise <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]> 
Hi Christopher,

Thanks for bringing our attention to this forgotten issue.
As you can see from the diff between RFC5101 and the RFC5101bis draft, 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-00.txt, 
the definition has not been changed. Out of the 6 proposals, which I 
will repeat with correct alignment

    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.

Since we have the RFC5101bis, we should change the "IP Traffic Flow" 
definition.

Regards, Benoit.


> Hello Benoit and others,
>
> I came across this old thread and was curious if there was any further outcome.  This is the last message I see in the thread, and there is indication that it might have been discussed more in person.   I have been through some, but not all IPFIX documents and could not find and other references.
>
> Thanks
> ...cj
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Benoit Claise
> Sent: Tuesday, October 26, 2010 8:35 AM
> To: Brian Trammell
> Cc: [email protected]
> Subject: Re: [IPFIX] Flow in IPFIX ->  not only IP Flows
>
> 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
>>>> [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
>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.