1. IP Flow Information eXport (IPFIX)
Web Site:
Mailing list info:
Meeting slides, minutes will be available at:

2. IPFIX WG Meeting, IETF 56
Administrivia: scribe, attendance sheets, slides
Agenda Review, additions? (5 mins)
Requirements Draft (Juergen Quittek, 10 mins)
Evaluation Process:
Updates to Advocacy Drafts, (Benoit Claise, 10 mins)
Draft-claise-ipfix-eval-netflow-04
Discussion: Evaluation Team's Selected Protocol (Chairs, 55 mins)
Review of WG Milestones (5 mins)

3. IPFIX WG Meeting, IETF 56
IPFIX-PSAMP relationship, (Benoit Claise, 10 mins)
draft-quittek-psamp-ipfix-01
Measurement and Monitoring draft (Supratik Bhattacharyya, 15 mins)
Draft-ietf-monitoring-sprint-01
"Requirements for integrating monitoring with operations,and thorny issues such as the problem of data export."
Wrap up

4. IPFIX Evaluation Results
The evaluation team recommends using NetFlow v9 as a basis for the IPFIX protocol
Attempting to quantify evaluation in a compatibility matrix was a dead end. No significant new information has appeared since our last meeting.
Our charter directs us to specify an IPFIX system which is "amenable to router and instrumentation implementors, and to deployment." The team believes that the IPFIX protocol, based on NetFlow v9, can be implemented in the most network elements because it makes the least demands of the exporter.

5. IPFIX Evaluation Results
Once we have consesus for NetFlow v9, via mailing list, the team suggests that the following should be addressed:
sub-second time-stamps
flow-loss statistics
clarify that exporter id isn't necessarily the transport source address (for proxying and fanouts)
Openness to reliability extensions per requirements
Fail-over, consider rserpool applicability draft:
Draft-coene-rserpool-applic-ipfix-00

6. An IPFIX Implementation Proposal
Specify that the initial IPFIX transport be TCP
This is a transition mechanism to enable rapid development and deployment of IPFIX.
Why? Because TCP is the only ubiquitous standard Congestion-Controlled transport protocol.
However, the IPFIX protocol MUST NOT rely on TCP's reliable delivery. Instead, it MUST remain compatible with unreliable datagram delivery so that it can be ported to upcoming transport protocols such as DCCP or PR-SCTP.

7. Next Steps The chairs and evaluation team propose:
Simon Leinen's evaluation ID, with conclusions added, be adopted as the IPFIX Evaluation Report and submitted to IESG for publication as an Informational RFC
Draft-leinen-ipfix-eval-contrib-00
An IPFIX protocol ID be prepared:
Draw details, but not content directly, from the NetFlow v9 advocacy draft
Do away with the advocacy draft in favor of this new protocol draft, ultimately intended to be proposed as standard
We'll need an editor for the protocol ID

8. IPFIX WG Meeting, IETF 56 Next Steps
IPFIX document roadmap:
IPFIX-ARCHITECTURE
Explains how IPFIX systems work
IPFIX-DATAMODEL
Enumerates and describes the IPFIX flow attributes
IPFIX-PROTOCOL
Describes the IPFIX protocol and encodings
IPFIX-APPLICABILITY
Describes typical uses of IPFIX systems
required for standards track

9. IPFIX WG Meeting, IETF 56 Review of WG Milestones (10 mins):
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
Done Submit IPFIX-REQUIREMENTS to IESG for publication as Informational RFC
APR 03* Submit Internet-Draft on IPFIX Protocol Evaluation Report
APR 03* Select IPFIX protocol, revise Architecture and Data Model drafts
APR Submit IPFIX Protocol Evaluation Report to IESG for publication as RFC
AUG 03* Submit Internet-Draft on IP Flow Export Applicability Statement
AUG 03* Submit Internet-Draft on IP Flow Export Protocol
DEC 03* Submit IPFIX-ARCHITECTURE to IESG for publication as Informational RFC
DEC 03* Submit IPFIX-INFOMODEL to IESG for publication as Proposed Standard RFC
DEC 03* Submit IPFIX-PROTOCOL to IESG for publication as Proposed Standard RFC
DEC 03* Submit IPFIX-APPLICABILITY to IESG for publication as Informational RFC