========================================= Minutes of the IPFIX session at IETF 70 Vancouver Tuesday December 4 at 1300-1500 Taken by Rolf Wolter ========================================= The session was chaired by Simon Leinen 1. Intro Simon explained that the ipfix WG has been re-chartered Previous charter documents are reviewed first. 2. Internet-Draft status In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-protocol-26.txt - draft-ietf-ipfix-info-15.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-biflow-05.txt - draft-ietf-ipfix-reducing-redundancy-04.txt Some delay due to interdepence with psamp, e.g. applicability draft and others ipfix mib: some outstanding work items Psamp status: Last call completed, new versions required Psamp framework, psamp-sample-tech, psamp-protocol 3. Drafts from the current charter a) Implementation Guidelines (Elisa Boschi) - draft-ietf-ipfix-implementation-guidelines-08.txt Status: the draft is almost complete, went to IETF and IESG review, some comments. New version has been posted by Nevil on his page. New paragraph in SCTP section added Comment from transport directorate: They wanted a statement that expresses that UDP is not recommended A comment on using RFC2119 language (MUST, SHOULD) applied b) IPFIX Testing (Paul Aitken) - draft-ietf-ipfix-testing-03.txt Status: publication has been requested Manor changes to previous version, such as simplifications, clarifications c) IPFIX MIB (Benoit Claise) - draft-ietf-ipfix-mib-01.txt Deadline missed, draft was posted yesterday, speed up process last call No changes on structure and RO/RW Terminology section removed All open issues have been resolved Ready for last call after this week Simon: did we get enough reviews yet? A: not yet, expected during last call 4. New Charter Following extensive discussions on the IPFIX list, a draft new charter was posted on 17 Oct 07. A request to re-charter the WG was submitted to IESG on 25 Oct 07. The final adoption will be assessed by the chairs based on the discussion on the mailing list. Milestones: Jan 2008 Publish Internet draft on IPFIX Mediation Problem Statement Jan 2008 Submit File Format draft to IESG for publication as Standards track RFC Jun 2008 Submit Type Export draft to IESG for publication as Standards track RFC Jun 2008 Submit Single SCTP Stream draft to IESG for publication as Informational RFC Oct 2008 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Oct 2008 Submit Mediation Problem draft to IESG for publication as Informational RFC Multiple documents, discuss adoption by WG. Simon explained what happens if an individual submission gets included in the WG a) IPFIX File Format (Brian Trammell) - draft-trammell-ipfix-file-05.txt Summary of the draft: standard flow storage format is useful for interoperability, flat binary files are ideal for flow storage. Changes to v4 include more examples, applicability to NetFlow v9 for converting these into ipfix. Next: continue to gain implementation experiences with ipfix files, ready for submission in January. Comments: Benoit: architectural assumption, e.g. routers write directly into files, should be clarified to avoid confusions. This leads to questions such as: how often to write, compress etc. A flow separator in the file could be useful, e.g. which device exported, which format etc. Brian: should be discussed in the WG, it makes sense to add it to the draft. A few people have read the draft (~10), most it's ready for adoption (~8). No votes against. b) Configuration Data Model (Benoit Claise) - draft-muenz-ipfix-configuration-03.txt The idea was to develop the data model based on ipfix and psamp data model. Added notes and clarifications on TemplateIDs. Multiple comments provided on the XML schema Data export into a file was added Filter added, such as access list, today AND filters in psamp, OR required. Config parameters for packet size and delay added, should be a vendor specific tag. Changes to config data model: export process restructured Open issues: file export - add option directly write into files file import - necessary? To be discussed on the list selection process, SCTP Should netconf be mandated? Consensus to recommend but not mandate Next steps: new draft by end of year Readers: not widely reviewed. More reviewers welcome! Adoption to be discussed on the list c) Extended types in IPFIX (Elisa Boschi) - draft-boschi-ipfix-exporting-type-00.txt Exporting Type Information for IPFIX Information Elements The name was changed from "Extended" to "Exporting", therefore the name went back to 00. Problem statement: ipfix provides no mechanism for representing IM properties within an ipfix message stream. This requires external references. History explained, started in 2005. Every dimension provided for IE from ipfix is supported. Future work: submit version 00 as a WG item after this week, final draft expected by June Paul: does this draft encourage to use Enterprise specific IE instead of standard elements and therefore never standardize? People should be encouraged to use the standard. Brian: we should avoid that people use Enterprise specific IE at a wider range, standard IEs should be used. New IE should be standardized. Paul: standardized elements should be used whenever possible Roman: is this a set of rules / data model language for exporting proprietary information, including registry changes. New products/technologies will use proprietary information to avoid delay introduced by IETF until a standard element is defined. Can a similar approach as with SNMP MIBs be used to easily standardize new IE? Clarification should be added to the document and explain transition process. Brian: technical transition process should be explained. Direct mapping was discussed in the past. If adopted, this needs clarification Benoit: is there guidance to prevent errors, e.g. wrong types for time etc. Elisa: not described yet, should be added. Multiple references to the data model. 6 people have read the draft, 4 people think it should be added to WG. No votes against. d) IPFIX Per-Stream SCTP reporting (Benoit Claise) - draft-claise-ipfix-export-per-sctp-stream-02.txt Idea: export each template in a single stream. Advantage: report data lost per template, already specified in ipfix requirements. Transmission order is maintained, i.e. data records couldn't arrive before template records. Solution: add new streams with the existing SCTP association OR use stream 0. Problem: usually the same option template is used for multiple streams, this needs to be addressed. Approach: sending the option in every stream is not possible (prevented by protocol draft). Some ideas proposed, not finalized solution yet. E.g. last used stream that used the option template sends it. Draft was completely rewritten, feedback and review required. 2 people have read the draft, Ready for adoption: 1 person Simon: this document is closely related to the new charter - some work in this area required. e) IPFIX Mediation, 2 individual submission: Kobayashi Atsushi, Christoph Sommer - draft-kobayashi-ipfix-mediator-model-01.txt - draft-dressler-ipfix-aggregation-04.txt The goals here are to produce two documents: - 'IPFIX Mediation: Problem Statement' - 'IPFIX Mediation: Framework' - draft-kobayashi-ipfix-large-ps-00.txt (Kobayashi Atsushi) IPFIX Mediation Problem Statement: Issue: in large ISP networks with thousands of routers the number of exported flow records exceeds 500 Gb/s. MPLS is used for traffic engineering and VPNs. Sampling is required, the biggest challenge in the future is scalability Approach: introducing hierarchical flow collection with concentrators How to distinguish separate network flows, e.g. VPNs and Internet share the same network infrastructure Idea: use flow classifier. Conclusions: concentrators are useful, however data might get lost and a device between Exporter and Collector needs more function other than Concentrator. Ralf: please clarify where data get lost. Answer: aggregation and correlation reduced the granularity of the original collection Dan: concern that this proposal introduces functions beyond the initial definitions, e.g. the classifier/concentrator might not be the right approach for scalability. Simon (speaking as operator): these issues even occur in smaller networks which requires an extraction process e.g. separate internal / external traffic Dan: why do we need a standard? Simon: today the export is proprietary, it would be easier to have it in standard format Dan: does this fit into ipfix? It reminds me to session border control Kobayashi: today these information are sent to multiple collectors and the collector has to apply the filtering, the classifier simplifies it. 4 people have read the draft, ready for adoption: 1 person - draft-kobayashi-ipfix-mediator-model-01.txt IPFIX Mediation Framework (Atsushi Kobayashi) Definition: ipfix mediation = ipfix protocol mediation and flow mediation Added ipfix distributor device as ipfix mediators Observation domain ID explained = largest set of observation points Next steps: write first framework draft, implementation of mediator - draft-dressler-ipfix-aggregation-04.txt (Falko Dressler) The draft was started in 2005. Aggregation = (1) flow selection and (2) compound flow creation After the selection criteria it becomes common property. Minor changes only. Problematic combinations described, e.g. allow any field vs. discard field values. Example described Open issues already mentioned before. - draft-sommer-ipfix-mediator-ext-00 (F. Dressler) Mediator-Specific Extensions to IPFIX Protocol and Information Model Motivation: current ipfix Protocol and Information Model: doesn't address bandwidth-efficient transport of compound flows. Rich template proposed. Summary: two new IEs added: ipv4Network and portRanges; 2 different approaches to increase transmission efficiency Brian: the charter says we should not change the template format, which the Rich template does, so it would need to be specified in the charter. - draft-irino-ipfix-ie-order-03 (Hitoshi Irino) Guidelines for the order of Information Elements Please refer to the presentation for details: http://www3.ietf.org/proceedings/07dec/slides/ipfix-1.pdf No discussions. - draft-kobayashi-ipfix-multicast-measure-00 (Kobayashi Atsushi) IPFIX Multicast Measurement Please refer to the presentation for details: http://www3.ietf.org/proceedings/07dec/slides/ipfix-5.pdf Presentation slides are be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 (search for IPFIX in the Operations and Management Area)