Minutes of the IP Flow Information eXport (IPFIX) WG IETF 55, Atlanta, Thursday November 21, 2002 49 people in attendance Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from scribes Cindy Mills, Chris Elliot, and George Michaelson The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF55/ Mark Allman gave a short "public service announcement" regaring the IMRG: http://www.irtf.org/charters/imrg.html http://imrg.grc.nasa.gov/imrg/ Opening remarks from the chair: IPFIX charter remains the same. Focus is on 'base level' standard which supports what people do now using one-way transport, but should not lock out the ability to do a next level on top of IPFIX that can provide different levels of transport reliability/service. The Applicability Draft "draft-zseby-ipfix-applicability-00.txt" was adopted as a WG draft by a hum, i.e. the next version will be submitted as a WG draft. Juergen Quittek presented the requirements draft "draft-ietf-ipfix-reqs-07.txt". Regarding the requirement of reporting ICMP type and code it was agreed by a hum that the requirements document will be updated to say SHOULD rather than MUST. No objections were raised regarding leaving the document as-is with respect to these issues: - VPN-ID attribute - exporting NAT'ed flows - Ignore Port Copy - anonymization - MPLS label/FEC - enabling de-duplication of received records Paul Calato reminded us about the outstanding issue of requiring the export to identify which flow attributes were used to distinguish the flows, i.e. which were part of the "flow key". He will supply clarifying text for the requirements document. The issue of reliability was discussed. Juergen proposed, and it was agreed to by a hum, that the requirements document should specify that the IPFIX protocol MAY have "aditional reliability" and that it MUST be open to reliability extensions. Tal Givoly will supply clarifying text about this higher level of reliability, describing it in an implementation independent way. Reinaldo Penno presented the evaluation team's report. None of the protocols conform to the requirements as they stand today. He suggest that two more revisions of the advocacy drafts and evaluation report would probably be required. It was pointed out that IPDR shouldn't be marked as "'F'ailed" for Pull Mode reporting, since it is a supported IPDR mode. (The editor is requested to correct this.) Various participants expressed concern that the evaluation summary (requirements compatibility matrix) did not indicate the importance of the requirements or other distinguishing features of the candidate protocols. It was suggested that advocates must elaborate on how their protocol will be extended, it is not sufficient for an unexplained "'E'xtension Needed" status to appear in the evaluation matrix. For example, an advocate who proposes to use SCTP for transport or IPSEC for security must explain which modes and/or options of these protocols will be used to comply with the IPFIX requirements. The evaluation team can take into account the degree of difficulty to implement the extension. Arguments were made for and against the current list of compatibility status values, including proposals to discard the "'U'pcoming" status, to further differentiate amongst the candidate protocols. However, no consensus was reached. A member of the evaluation team commented that the team is to look at protocols, not products, therefore installed base is not an important feature, a well-defined protocol is what's important. Evaluators should decide if protocols can be implemented at reasonable cost. Another member of the team said that the team should complete this document and give it back to the advocates so that the advocates can see how much effort they neec to expend to make their E's into T's. Reinaldo agreed to submit the "-00" draft for commentary as soon as possible. To accelerate the evluation process, the chair encouraged the advocates to critically evaluate each others protocols, and to interact with the evaluation team members (in the public IPFIX mailing list). Bert Wijnen, sitting in as our Area Director, reminded us that the working group, not necessarily the advocate, will modify the protocol as it sees fit once it has been selected as the IPFIX starting point. Juergen Quittek, co-chair of the PSAMP working group, gave a short presentation on possible synergies between PSAMP and IPFIX. Nevil reviewed the milestones and the following updates were suggested, to which there were no objections: - the evaluation draft version "-01" (or greater) will be submitted by late January, 2002. - the applicability document versions will be postponed until after the selection of one of the candidate protocols. - the starting-point IPFIX protocol will be selected in the March/April timeframe.