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.
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.
| 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
<ipfix-chairs@net.doit.wisc.edu>].
--
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
|