Re: [IPFIX] Flow in IPFIX -> not only IP Flows
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Brian,
Agreed to your changes.
Agreed that there is no impact changing those definitions.
On this point:
These are pretty simple changes and I don't see any problem just making them. 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. :)
IPFIX is exporting non IP flows, this is happening. Full stop.
IPFIX became a generic PUSH mechanism.
Do we want to change the name. Too late I would say.
However, I still believe that an applicability version 2 document will
be required at some point in time in the future.
Regards, Benoit.
> Hi, Benoit, all,
>
> I believe that there's enough interest in layer 2 export that we've kind of already started applying IPFIX to non-IP packets, so to some extent both 4. and 5. would be simply a matter of aligning the 5101bis draft (perhaps as well as its shadow, 5101 + errata) with current reality. Both carry the caveat that we have to think about all the implications. But I think there is nothing about the present definition that breaks when you remove 'IP' from it. Indeed, I think the only thing to do is to remove "IP" from a couple of places, as follows, from 5101bis.
>
> OLD:
>
> 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]).
>
> 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.
>
>
> NEW:
>
>
> 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 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]).
>
> 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.
>
>
> Even the ancillary definitions (e.g. Flow Key) already work in the context of non-IP flows. Observation Point would also have to be changed:
>
>
> OLD:
>
> An Observation Point is a location in the network where IP packets
> can be observed. Examples include: a line to which a probe is
> attached, a shared medium, such as an Ethernet-based LAN, a single
> port of a router, or a set of interfaces (physical or logical) of a
> router.
>
> NEW:
>
> An Observation Point is a location in the network where packets
> can be observed. Examples include: a line to which a probe is
> attached, a shared medium, such as an Ethernet-based LAN, a single
> port of a router, or a set of interfaces (physical or logical) of a
> router.
>
>
> These are pretty simple changes and I don't see any problem just making them. 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. :)
>
> Cheers,
>
> Brian
>
>
>
>
> On Feb 24, 2012, at 10:21 AM, Benoit Claise wrote:
>
>> 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