Last Modified: 2003-02-26
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.
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.
|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|
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: http://ipfix.doit.wisc.edu/IETF56/ [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 changes] -- 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 address * 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 oranges. 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 comment.] 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 <firstname.lastname@example.org>]. -- 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 attributes. 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 "draft-quittek-psamp-ipfix-01". [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: "draft-bhattacharyya-monitoring-sprint-01". [see slides for details, further information at: http://ipmon.sprint.com] 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 here: http://www.jabber.com/chatbot/logs/conf erence.ietf.jabber.com/ipfix/2003-03-20.html