Last Modified: 2003-10-16
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 | |
| Done | Submit Internet-Draft on IPFIX Protocol Evaluation Report | |
| Done | Submit Internet-Draft on IP Flow Export Applicability Statement | |
| Done | 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 Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 58, Minneapolis, Monday November 10, 2003
58 people in attendance
Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from
Greg Ruth and George Michaelson.
The text messaging log is available here:
http://www.xmpp.org/ietf-logs/ipfix@iet
f.xmpp.org/2003-11-10.html
The meeting agenda and slides are available here:
http://ipfix.doit.wisc.edu/IETF58/
[please see the agenda slides there for the sequence of topics:
http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf]
--
Juergen Quittek presented an update on the requirements draft.
[see slides for details:
http://ipfix.doit.wisc.edu/I
ETF58/IPFIX-reqs-IETF58.ppt]
Nevil reported that, based on a conversation with Allison Mankin
(transport area director), anonymsization IPFIX simply MAY be
required, rather than MUST as she had suggested previously. However, the
requirements draft should include the rationale for why this is not
strictly required. (Basically that there is not yet a standard
anonymization method.)
--
Ganesh Sadasivan presented an update on the architecture draft.
[see slides for details:
http://ipfix.doit.wisc.edu/I
ETF58/IPFIX_Architecture.ppt]
We need volunteers to provide more text, in this and other drafts.
--
Juergen Quittek presented an update on the information model draft.
[this was an oral report only: no slides.]
Not many changes have been made recently.
--
Benoit Claise presented an update on the protocol draft.
[see slides for details:
http://ipfix.doit.wisc.edu/I
ETF58/IETF-58-IPFIX-PROTO.ppt]
The draft has had many changes as the result of feedback regarding the
NetFlow v9 draft, to be submitted as an individual Information RFC, which
Benoit has been editing in parallel with the IPFIX protocol draft.
Would like feedback regarding a number of issues listed in the slides:
1) Do we have consensus to use an options data record per
observation domain and per template?
2) Do we have consensus to replace the count with a length field, in the
export packet header?
Lastly, he noted that the issue of transport protocol and Vendor
Specified Information Elements are open issues. (These were addressed
below.)
--
Tanja Zseby presented an update on the protocol draft.
[see slides for details:
http://ipfix.doit.wisc.edu/I
ETF58/IPFIX-applicability-ietf58.pdf]
Highlights included that the middlebox content was removed.
It was suggested that the applications discussed in the draft be limited to
those that are considered high priority, so as to limit the amount of
work.
--
Stuart Bryant presented his draft on Vendor Specified Information
Elements.
[see slides for details:
http://ipfix.doit.wisc.edu/IETF58/FIXME]
He suggested that IPFIX adopt the "compressed VI qualified"
implementation.
Those present afreed that text from this draft be copied directly into the
IPFIX protocol draft.
--
Morizio Molina presented his draft on Flow Selection.
[see slides for details:
http://ipfix.doit.wisc.edu/I
ETF58/draft-molina-flow-selection-00.ppt]
While the chairs agree that this notion is worth considering, it will not be
part of the current IPFIX documents. However, IPFIX reviewers should take
care not to preclude the implementation of such features in the future.
--
Nevil Brownlee present his short list of open issues.
For each, consensus at the meeting was:
1) Both counter and gauge types are needed in the information model.
[Here, the chairs suggest considering counter and gauge, a la SNMP
such as defined in section sections 7.1.6 and 7.1.7 of RFC-2578.]
For most information elements (IE), one or the other is
sufficient, and IPFIX should specify which MUST be implemented for each IE.
For some, such as packet and byte counts, both types may be
required.
2) The consensus was that a UTC-based seconds and microseconds,
similar to Unix struct timeval, should be adopted.
The IPFIX implementation may need to report its time
resolution, which presumably would require new text in the protocol
draft.
It was noted that 32-bit unsigned counter wraps (c.) should be
defined (note precedent from NTP specification).
3) Variable length information elements are needed, and are being
addressed in the information model.
4) IPFIX templates will specifiy the number of bytes, ie. the
encoding, used for numeric information elements. (The information model
specifies only the range.)
--
At this point we opened discussion regarding the default (MUST
implement)
transport for IPFIX.
Randy Bush, our area director, reminded us that one specific transport MUST
be implemented to ensure interoperability (the goal of the IETF in
general).
In response to issues raised recently in the mailing list
questioning the IETF's approval of UDP-based RTP to deliver
high-bandwidth HDTV content, Jon Peterson (transport area director) said
that the IESG expects IPFIX to work within the letter of its existing
charter (and therefore must not use a UDP-based transport). He also said
that the IESG was mistaken, and in hindsight should not have approved the
use of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").
--
In the context of this transport discussion, Randall Stewart
presented a slideshow about SCTP and PR-SCTP.
[see slides for details:
http://ipfix.doit.wisc.edu
/IETF58/IETF-58-IPFIX-Transport-bclaise-comment.ppt]
Randall hypothesized that PR-SCTP may be available as a standard as
soon as two months from now.
--
Based on past IPFIX meeting discussions and in the mailing list, the
chairs claimed that they felt there was rough consensus for choosing TCP as
the default transport for IPFIX.
A show of hands in the meeting showed otherwise, with more favoring SCTP
than TCP. However, many did not express an opinion. This issue will be
taken to the mailing list to test the meeting consensus.
--
Nevil reviewed the working group milestones:
The requirements draft and evaluation report will be submitted by
December 1, 2003.
The other four drafts need text and editing, and we're shooting for May 31,
2004.
--
$Id: minutes.txt,v 1.9 2003/12/11 20:32:06 dplonka Exp $
|