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

From: Christopher White <[email-masked]>
Date: Wed, 22 Feb 2012 16:43:52 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, October 26, 2010 8:35 AM
To: Brian Trammell
Cc: [email-masked]
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-masked]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Feb 2012 10:21:04 +0100

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...

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

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 24 Feb 2012 10:41:34 +0100

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:

> 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
> Since we have the RFC5101bis, we should change the "IP Traffic Flow" definition.
> 
> Regards, Benoit.
> 
> 
>> Hello Benoit and others,
>> 
>> From: 
>> [email-masked] [mailto:[email-masked]
>> ] On Behalf Of Benoit Claise
>> Cc: 
>> [email-masked]
>>>>>>              fields [RFC3550
>>>>>> <http://tools.ietf.org/html/rfc3550>
>>>>>> ]).
>>>>>>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 24 Feb 2012 10:23:36 +0000

Brian,

> 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.

P.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 24 Feb 2012 11:27:43 +0100

Hi, Paul.

Of course, if you get rid of IP and Flow out of the title, you're just left with IX, and now we're colliding with entirely different acronyms. :)

But this is a good point, and I'll use it in the future.

Cheers,

Brian

On Feb 24, 2012, at 11:23 AM, Paul Aitken wrote:

> The existing IANA elements show that it can measure metrics at any layer. Even "flow" isn't so relevant these days.
>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 24 Feb 2012 10:36:35 +0000

Brian,

Considering 5101, structured data, and export of mib objects, I suggest 
"Export of Information Elements and Irregular Objects", EIEIO.

P.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Feb 2012 11:35:34 +0100

Brian,

Agreed to your changes.
Agreed that there is no impact changing those definitions.

On this point:

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.

---

From: Christopher White <[email-masked]>
Date: Fri, 24 Feb 2012 20:33:19 +0000

Hi Paul and Brian,

> From: Paul Aitken [mailto:[email-masked]]
> > 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.
> 

[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.  

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.

...cj

---

From: Brian Trammell <[email-masked]>
Date: Fri, 24 Feb 2012 22:24:34 +0100

> 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 i…

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 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…

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

---

From: Nevil Brownlee <[email-masked]>
Date: Sun, 26 Feb 2012 11:15:18 -0800

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

-- 
---------------------------------------------------------------------
  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

---

From: Brian Trammell <[email-masked]>
Date: Mon, 27 Feb 2012 07:52:25 +0100

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

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 27 Feb 2012 07:55:10 +0000

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-masked]> 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
>
>>>>>layer.
>>>> 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.
>>> 
>>>> 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
>>>