Last Modified: 2005-01-19
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 | |
Done | Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC | |
Done | Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC | |
Sep 04 | Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC | |
Sep 04 | Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC | |
Sep 04 | Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC | |
Sep 04 | Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC |
RFC | Status | Title |
---|---|---|
RFC3917 | I | Requirements for IP Flow Information Export |
RFC3955 | I | Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) |
Minutes of the IP Flow Information eXport (IPFIX) WG
62nd IETF, Minneapolis, Thursday March 10, 2005 35 people in attendance submitted by Dave Plonka and Nevil Brownlee (co-chairs) based on notes from George Michaelson, Simon Leinen, and Ralf Wolter. The text messaging log is available here: http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2005-03-10.html The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF62/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF62/0-ietf62-ipfix-agenda.pdf ] ---- The chairs mentioned that the four drafts are at the tail end of a WG last call currently. We're optimistic because The documents have improved greatly during this process, thanks to the authors/editors and contributions from reviewers. There were no objections raised to discussing the very recent (yet-to-be-published) changes to the documents. Our target is to submit them to the IESG by mid-April. David Kessens (our Area Director) reminded the working group that we need to get this work done now because of PSAMP depending on IPFIX and because he is hearing from industry folks that want it. ---- Architecture draft changes (Nevil Brownlee) [see slides for details: http://ipfix.doit.wisc.edu/IETF62/1-ietf62-ipfix-brownlee-arch.pdf ] ---- Protocol draft changes (Benoit Claise) [see slides for details: http://ipfix.doit.wisc.edu/IETF62/2-ietf62-ipfix-claise-proto.ppt ] version 10 of this draft will be posted next week. There appears to be consensus on the term Data Record (rather than Flow Data Record) as discussed recently in the mailing list. There is an open issue regarding the micro/milli-second timestamp deltas relative to what is currently called the "export time". This will be discussed after Juergen presents it in the information model discussion (below). ---- Information model (Juergen Quittek) [see slides for details: http://ipfix.doit.wisc.edu/IETF62/3-ietf62-ipfix-quittek-info.ppt ] In response to a question as to whether or not there is a IANA registry for the information elements that can be used to define scope (such as lineCardId), Juergen and Benoit pointed out that any information element can be used to define scope, but some make much more (or less) sense than others. So, we just have one registry for all IPFIX information elements. There is a proposal to use 32-bit rather than 64-bit values as delta/offset times from a base time. Currently the message header has a time field called "export time". If this were used as the base for delta times, they would have to be signed negative values (for the start and end of the flow) or implictly negative unsigned values. So, depending upon what is chosen as the base time, the relative timestamps might be positive or negative. Which do we prefer? Simon Leinen suggested that an arbitrary base time (of the implementer's choosing) that is before the start or equal to the oldest time might be better than "export time" which may be interesting, but not of much use in practice. This requires only positive values for relative timestamps and permits some performance optimizations because it would not be necessary to make additional passes across the flow data to fix these relative timestamps prior to export. Others suggested that the export time be preserved as-is because it is useful when an exporter lags, and that perhaps an additional base time be added as an information element. Nevil noted that there is no simple way to make such a change to the protocol at this point. Juergen mentioned that there is a sourceId in the message header that is used to define a sort of scope, this is potentially unnecessary or ambiguous since information elements could be used to define scope. Should sourceId be an information element instead? There was insufficient time to discuss the timestamp and sourceId issues at length, so we will continue it in the mailing list. ---- Applicability statement (Tanja Zseby) [see slides for details: http://ipfix.doit.wisc.edu/IETF62/4-ietf62-ipfix-zseby-applicability.ppt ] ---- IPFIX Aggregation (Juergen Quittek for Falko Dressler) [see slides for details: http://ipfix.doit.wisc.edu/IETF62/5-ietf62-ipfix-dressler-aggregation.ppt ] This was a discussion about a new draft discussing aggregation techniques for devices or environments where it is not feasible or desired to report all 5-tuple flows. The chairs encouraged feedback to Falko on this draft. ---- Per-Packet Information Export (Elisa Boschi) draft-pohl-perpktinfo-02.txt [see slides for details: http://ipfix.doit.wisc.edu/IETF62/6-ietf62-ipfix-boschi-perpktinfo.ppt ] Elisa mentioned that a flowId information element has been added so that, now, no further changes to IPFIX are needed to make this work. So, now which working group's document should this be integrated into: IPFIX or PSAMP? The chairs suggested that we have the right split now, the required information element is in the IPFIX draft, so the rest of the work could continue to PSAMP. This will prevent the integration of this new content from slowing the process of taking the IPFIX drafts through to RFC as soon as possible. There was some general discussion and concern that IPFIX work needed to continue. It was noted that even if IPFIX doesn't meet continually, the WG can still exist (or recharter, theoretically) and continue pertinent work. Our focus now though is to get the existing work and with both IPFIX and PSAMP there is a place for this work. ---- The chairs propose doing one more WG last call on each of the documents once the next revision is published. We'll ask the ADs to push our milestone deadlines out 21 days to a month from now. Propose submission to IESG for publication by mid-April, 2005 -- $Id: minutes.txt,v 1.4 2005/03/28 22:07:33 dplonka Exp $ |