2.4.7 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-26

Nevil Brownlee <n.brownlee@auckland.ac.nz>
Dave Plonka <plonka@doit.wisc.edu>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: ipfix@net.doit.wisc.edu
To Subscribe: majordomo@net.doit.wisc.edu
In Body: subscribe ipfix
Archive: http://ipfx.doit.wisc.edu/list/ipfix/archive/
Description of Working Group:
There are a number of IP flow information export systems in common use. These systems differ significantly, even though some have adopted a common transport mechanism; such differences make it difficult to develop generalised flow analysis tools. As such, there is a need in industry and the Internet research community for IP devices such as routers to export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as Internet research, measurement, accounting, and billing.

An IP flow information export system includes a data model, which represents the flow information, and a transport protocol. An "exporter," which is typically an IP router or IP traffic measurement device, will employ the IP flow information export system to report information about "IP flows," these being series of related IP packets that have been either forwarded or dropped. The reported flow information will include both (1) those attributes derived from the IP packet headers such as source and destination address, protocol, and port number and (2) those attributes often known only to the exporter such as ingress and egress ports, IP (sub)net mask, autonomous system numbers and perhaps sub-IP-layer information.

This group will select a protocol by which IP flow information can be transferred in a timely fashion from an "exporter" to a collection station or stations and define an architecture which employs it. The protocol must run over an IETF approved congestion-aware transport protocol such as TCP or SCTP.

Specific Goals

o Define the notion of a "standard IP flow." The flow definition will be a practical one, similar to those currently in use by existing non-standard flow information export protocols which have attempted to achieve similar goals but have not documented their flow defintion.

o Devise data encodings that support analysis of IPv4 and IPv6 unicast and multicast flows traversing a network element at packet header level and other levels of aggregation as requested by the network operator according to the capabilities of the given router implementation.

o Consider the notion of IP flow information export based upon packet sampling.

o Identify and address any security privacy concerns affecting flow data. Determine technology for securing the flow information export data, e.g. TLS.

o Specify the transport mapping for carrying IP flow information, one which is amenable to router and instrumentation implementors, and to deployment.

o Ensure that the flow export system is reliable in that it will minimize the likelihood of flow data being lost due to resource constraints in the exporter or receiver and to accurately report such loss if it occurs.

Goals and Milestones:
Done  Submit Revised Internet-Draft on IP Flow Export Requirements
Done  Submit Internet-Draft on IP Flow Export Architecture
Done  Submit Internet-Draft on IP Flow Export Data Model
NOV 02  Submit Internet-Draft on IPFIX Protocol Evaluation Report
DEC 02  Submit Internet-Draft on IP Flow Export Applicability Statement
FEB 03  Select IPFIX protocol, revise Architecture and Data Model drafts
APR 03  Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC
Done  Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC
AUG 03  Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC
AUG 03  Submit IPFX-DATAMODEL to IESG for publication as Informational RFC
AUG 03  Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC
  • - draft-ietf-ipfix-reqs-09.txt
  • - draft-ietf-ipfix-architecture-02.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the IP Flow Information eXport (IPFIX) WG
    IETF 56, San Francisco, Thursday March 20, 2003
    approx. 60-80 people in attendance
    Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from 
    scribes Greg Ruth and George Michaelson.
    The meeting agenda and slides are available here:
    [please see the agenda slides there for the sequence of topics below.]
    Juergen Quittek presented the requirements draft 
    "draft-ietf-ipfix-reqs-09.txt" and differences from -07 to -09.  This 
    draft has passed Working Group last call and has been submitted to IESG for 
    publication as an Informational RFC.  [see slides for details of 
    Benoit Claise presented updates to the NetFlow v9-related drafts for the 
    protocol evaluation process. [see slides for details]
    The chairs presented the evaluation process report on behalf of the 
    evaluation team.
    The results, as presented, were reviewed and approved by four of the 
    evaluation team members (three in person, one by email).  The fifth 
    member was not present and did not respond to email.  So, this report 
    conveyed the [rough] consensus amongst the evaluation team.
    The evaluation team has recommended NetFlow v9 as a basis for the IPFIX 
    protocol, the primary rationale being that:
     * Quantification through a candidate protocol compatibility matrix 
    produced no significant new information since the IETF 55 meeting.
     * The IPFIX charter directs us to specify an IPFIX system amenable to 
    router and instrumentation implementers and to deployment - i.e. the 
    solution must be feasible.
    Furthermore, once the WG has consensus for NetFlow v9 (via mailing list) the 
    team suggests that the following be addressed:
     * Sub-second timestamps
     * Flow-loss statistics
     * Clarify that the exporter ID isn't necessarily the transport source 
     * Openness to reliability extensions
     * Fail-over must be (re)considered (how reserpool may apply - see their 
    applicability draft)
     * Then, specify the initial IPFIX transport be TCP
    The rationale for specifying TCP as the transport is to enable rapid 
    development and deployment of IPFIX. TCP is a ubiquitous standard; DCCP and 
    PR-SCTP are not yet standards.  However, the IPFIX protocol must not rely on 
    TCP's reliable delivery; instead it must remain compatible with 
    unreliable protocols.
    Much discussion followed regarding both the selection process, about half of 
    which was initiated by the three advocates of the CRANE, IPDR, and LFAP 
    protocols.  Below are some Questions/Comments (Q:) to which the chairs 
    responded (A:):
     Q: It was not clear what the evaluation process was, or whether or not it 
    was followed.  LFAP appeared to be leading in the compatibility matrix 
    [presented at the previous meeting].
     A: (chair) As to the evaluation process, the [matrix-based] scoring 
    revealed no clear winner.  So the scoring system simply didn't resolve 
    which protocol to use.  Therefore, [the evaluation team] asked 
    themselves what we really want the protocol to do and tried to work with 
    that.  We don't believe this is a sudden change of direction.
     Q: There are two main categories of candidate protocols: "general data 
    movers" and [special-purpose] protocols.  This is like comparing apples and 
     A: (chair) Rhetorical: does the charter favor an apple or an orange?  The 
    evaluation process did not change; the evaluation team made the 
    decision.  There has been silence in the mailing list from the 
    candidate protocol advocates for months.
     Q: Protocols change dramatically during the course of being prepared by a 
    working group, on their way to IETF standard.  This is what the IETF and 
    working group process is for.  [presumably meaning, get on with it.  The 
    group will change the selected protocol as 
    necessary/appropriate.  Applause from audience in response to this 
     Q: The CRANE and IPDR folks are working on a new unified/merged 
    proposal [which may be a better candidate].
     A: (chair) We've not heard of this effort before, and this is not the 
    prescribed way to introduce a candidate protocol into the evaluation 
    process.  If [notification] didn't happen in the [IPFIX] mailing list, then 
    [the chairs and IETF must presume] that it didn't happen [at all].
     Q: Why TCP as initial transport?
     Q: There are about 30 SCTP implementations out there now.  Couldn't we 
    start with SCTP?
     A: TCP and SCTP are the only choices right now.  TCP is the obvious 
    choice - more widely available on both operating system platforms and in 
    language APIs.
     Q: NetFlow doesn't support TCP; was the goal really just to select 
    NetFlow?  Is the ability to put the protocol on different devices a 
    (heretofore) unstated requirement?  Is the intent to provide an impetus to 
    "fix" NetFlow?
     A: (Area Director) The notion of "fixing" NetFlow is originally what the 
    IESG thought [IPFIX] was going to do.  However, [standardizing NetFlow] 
    wasn't the WG's chartered goal, it was just a reasonable 
    expectation.  There was no hidden agenda.
     A: (chairs) Now is the time to propose "improvements" to the NetFlow 
    proposal [as it becomes the IPFIX protocol].
    [More general disagreement with the selection was expressed by the 
    advocates for the protocols that were not selected.]
     Q: Is there a willingness to modify NetFlow to incorporate good 
    features from the other candidate protocols?
     A: (chairs) Yes, we will change it as the IPFIX protocol, but 
    integration of features should be limited to only those necessary to meet 
    the IPFIX requirements.
        [chairs addendum for minutes: It's not necessarily relevant to our 
    IPFIX effort whether or not Cisco's NetFlow version `n' 
    incorporates these features/fixes.  Our proposed NetFlow v9-based 
    protocol will be a product of the IPFIX WG.]
    The chairs moved on to propose a process for going forward from the 
    evaluation team's selection.  It was proposed that Simon Leinen's 
    evaluation ID be a starting point for the evaluation team's report.  More 
    text will be integrated stating the rationale for this decision prior to its 
    submission to become an information RFC.
    Furthermore, it was proposed that a new IPFIX protocol draft be 
    prepared by the WG, drawing details (but not content directly) from the 
    NetFlow v9 draft.  This new IPFIX protocol draft is ultimately intended to 
    become a standards-track RFC.
    Also, the chairs noted that we'll need a (new) editor for the protocol ID.  
    Interested volunteers should contact the chairs
    [via email to 
    The chairs reviewed a slightly modified document road-map, including:
     * IPFIX Architecture
     * IPFIX Data Model
     * IPFIX Protocol
     * IPFIX Applicability
     Q: Will we add vendor specific features [/flow-attributes]?  NetFlow is 
    template based with a flat namespace for the attribute identifiers.
     A: (chair) An IANA-managed flat namespace may be an advantage in terms of 
    simplicity.  (chair not an expert on NetFlow v9 proposal, so defers to 
    others regarding TLV aspects of the protocol.)
     A: (others) Paraphrase: Yes, the NetFlow proposal is deficient in this 
    respect.  IPFIX needs to address the TLV issue so that a 
    NetFlow-based IPFIX protocol would be more extensible w.r.t. new 
     Q: Is this the time [now, in the meeting] to discuss the list of stuff 
    that IPFIX must support?  I question full the compliance of NetFlow for 
    IPFIX features.
     A: (chairs) Compliance issues need to be addressed (as noted by the 
    evaluation team [mentioned above], but we are not adding features to IPFIX 
    requirements.  At this point we want to get consensus that the 
    suggested process is the way forward, and move discussion of specific 
    details to the mailing list.
     Q: Shouldn't we merge some of the candidate protocols [rather than 
    choosing NetFlow]?
     A: (chairs) We needed to select one protocol to accelerate the 
    process.  We'll use that as a basis, something that will work soon, 
    incorporating other features only as necessary.
     Q: The evaluation check list was flawed: it was all or nothing (not 
    graded, prioritized) for each requirement.  Can we go back and score A-E to 
    clarify the decision?  It would make a more convincing case [for the 
    evaluation team's decision].
     A: (chairs) Do we want to go back to November 2002 with a finer grain 
    scoring?  The quantification is very difficult and problematic.  
    Rhetorical: do we think anything will be gained by jiggering the process to 
    justify the selection of NetFlow?  There were considerations beyond the 
    matrix of "scores", like NetFlow's wide deployment.
    At this point the chairs called for a show of hands, "How many support the 
    evaluation team's finding?" ("How many disagree?")  The shows of hands 
    indicated clearly that consensus of the room was for accepting the 
    finding and going forward.
    The chairs said final rough consensus will be determined from the 
    mailing list.  Also:
       (chairs) Now we are looking for volunteers to help write the next 
    documents.  We encourage your comments on the list.  Please limit it to one 
    comment per message so we can keep the threads straight!
    The chairs reviewed the revised WG Milestones:
    [see agenda slides for details]
       We've met some of our early milestones and some more are within reach.  We 
    will need an Applicability Statement.  Tanja Zseby agreed to continue with 
    this.  August 2003 suggested for this and the protocol document IDs.
    Benoit Claise presented a slide show about the relationship between IPFIX 
    and PSAMP based on 
    [see slides for details]
    Supratik Bhattacharyya presented a slide show on Continuous Measurent and 
    Monitoring in an ISP backbone related to Sprint Labs document on 
    operators' requirements: 
    [see slides for details, further information at: 
     Q:  What kind of reliability do you need?
     A: (Supratik) not entirely clear - reliability is certainly useful, but not 
    absolutely necessary.
    The meeting was adjourned with the reminder that follow-ups will happen in 
    the mailing list and that we need to find an "issues tracking" method for 
    the refinement/development of the IPFIX protocol.
    P.S. George Michaelson's (ggm) "live" notes instant messaging are logged 


    IPFIX Requirements: Document Changes from Version -07 to Version -09
    Evaluation of NetFlow Version 9 Against IPFIX Requirements: changes from version 03 to 04
    On the Relationship between PSAMP and IPFIX
    Network Measurement and Monitoring: A Sprint Perspective