===================================== Ip Flow Information Export WG (ipfix) IETF #74, San Francisco Monday, 23 Mar 09 at 1300-1500 Taken by Matt Zekauskas ===================================== Chairs: Nevil Brownlee Juergen Quittek 0) Session summary 1) Agenda review WG Status 2) Internet-Draft status 3) Information Element Registry status 4) Drafts submitted to IESG 5) Current WG drafts 6) Other drafts 0) Session Summary Four IPFIX documents (architecture, applcbility statement, reducing redundancy and testing) and four PSAMP douments are in thr RFC editor queue with status AUTH48 and will be published very soon. Three documents are in IETF last call (IPFIX MIB, exporting type information, IPFIX file format). The document on per SCTP stream reporting is ready for requesting publication. There are three remaining drafts on the IPFIX charter: The configuration data model, the mediation problem statement and the mediation framework. It was discussed whether or not to split the configuration data model document into an information model and a YANG-specific datamodel. Since the PSAMP WG has only the PSAMP MIB left on its charter it was considered to close the PSAMP WG and add the PSAMP MIB to the IPFIX charter. As poential new work items for IPFIX three items were discussed: anaonmization of flow records, flow selection/flow sampling, and structuring of data in IPFIX records. Discussion on new work items will be continued at the next meeting. 1) Agenda review and WG Status There were no requests to modify the agenda. 2) Internet-draft Status The status of WG IDs was described as in the session summary above. 2. Internet-Draft status = 5 min [In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt - draft-ietf-ipfix-testing-04.txt - draft-ietf-psamp-framework-13.txt - draft-ietf-psamp-sample-tech-10.txt - draft-ietf-psamp-protocol-09.txt - draft-ietf-psamp-info-11.txt] Juergen goes over IPFIX passed to IESG. Juergen: Any opinions on moving PSAMP MIB to ipfix charter and conclude psamp charter? There were no requests to change the agenda. info elts registry status. any issues? usu nevil's purview benoit? have time for potential new work. flow selection (from several years ago) flow anon support, now have more recnt draft to support handling structured data. 3) Information Element Registry status Benoit Claise: In RFC 5102 there is an error in one of the information elements. Shall we deprecate it or just correct it. Juergen: Once a standard is published, you cannot change it. Dan Romascanu: We need to define a new one and deprecate the old one. IANA has a status field for each RFC. There we should mark the old one as deprecated. Juergen: we should add a comment to the deprecated element in the IANA registry that points to the new element to be used. Paul Aitken (via Jabber): The issue is that the figure in the RFC does not agree with the text description. Also, the figure is not compatible with NetFlow RFC 3954. a) IPFIX File Format (Brian Trammell) ( 3 min) - draft-ietf-ipfix-file-03.txt 24 Oct 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt 14 Jul 08 ( 3 min) 4) Drafts submitted to IESG a) IPFIX MIB - draft-ietf-ipfix-mib-06.txt 9 Mar 09 Benoit explained progress and status of IPFIX MIB module, see slides. Authors received good feedback from MIB doctor review and improved the document. Open issue: We will need to add new selector functions in the future. We will pass control to IANA. Juergen: How would it work? Dan: IANA would maintain the definition of a TC. The TC would list all allowed values and the list can be extended by IANA. Benoit suggested removing the metering process ID in order to be consistent with the IPFIX data model. Benoit: Can we go to IETF last call Dan: You are already in. If the next version addresses well the comments received in the last call, then the document can be passed to the IESG. 5) Current WG drafts a) IPFIX Per-Stream SCTP reporting draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 Benoit presented slides. All issues have been solved. The document is ready for requesting publication Juergen: Will do so after the IETF meeting. Brian: no objection, point out that I spoke with nate Michael Tuexen today on agenda for tsvwg thurs afternoon, to have stream reseat be WG item. Doesn't change things here, but things moving along in TSVWG. b) Configuration Data Model draft-ietf-ipfix-configuration-model-02.txt, 6 Mar 09 Again Benoit presented the slides. Problem: We are referecing the PSAMP MIB which is not yet progressed far. Dan: Can you make it an informational refence? If yes, it will not be a problem. Benoit: We will try. Benoit pointed out that a prelimnary version of YANG is beimg used. David Partain: We plan to take YANG to WGLC after this IETF meeting. We hope to conclude at the end of the summer. Juergen: It is dangerous to wait. David: certainly, we expect to complet WG work by end of summer, but we don't know what the IESG will say about it. Juergen: It was already consensus in the last IETf meeting to split the document into two. Benoit: What about waiting until YANG has progressed. Juergen: If it would be for a certain number of months, I would be OK. But we don't know if and how YANG will pass the IESG. David Partain: Most of the discussion on whether or not to follow the YANG idea are done. Gerhard: I clearly prefer not to split the document. Juergen: We may wait for some more time for YNAG making progress. Dan: Leaving it open is also a kind of a decision. I don't know what will happen to YANG in the IESG. It is a new data modeling language and a complex work. From an architectural point of view, I would prefer to split information model and data model. Benoit: Can we ask the mailing list if there is an urgent need for completing this document? Juergen: Let's conclude the discussion on the mailing list. c) IPFIX Mediation Problem Statement draft-ietf-ipfix-mediators-problem-statement-02.txt 4 Feb 09 Atsushi Kobayashi presented the slides. There will be a revision needed. This will be available in a few weeks. Juergen: I will have a look at the next version and then start WGLC. Brian Trammell: Metadata should be exported on a per-operation basis. This means different sets of metadata to describe aggregation, anonymisation, or other mediation operations. Benoit: Agree with Brian. However, capabilities of mediators should be considered well. d) IPFIX Mediation Framework draft-ietf-ipfix-mediators-framework-02.txt 10 Feb 09 Atsushi Kobayashi presented the slides. Juergen: Shall it go together with the problem statement to WGLC? Atsushi: Better let's have the problem statement first. Comments received may have influence on the framework. 6) Other drafts a) Flow Selection draft-peluso-flowselection-tech-02 Tanja Zseby presented the slides. Unknown speaker: Isn't this like the mediator? Is the source source of where data is from considered when selecting flows? Tanja: Yes, it is in line with the mediation work. Flow selection can be one kind of processing at a mediator. We have not yet considered the source as criteria for selection but this sounds lke a good idea. Juergen: This is an interesting draft. We should consider it as potential WG item, but let's have a final discussion on it at the next meeting. Currently, we should focus on the mediation work. b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) draft-boschi-ipfix-anon-02 12 Jan 09 Jurgen: Anonymization was already included in the IPFIX requirements RFC, but at this time technology was considered not mature enough for including it in the IPFIX standard. Let's see if there has been some progress that changes the situation. Brian Trammell presented the slides. The presentation was on version -03 which is available at http://people.ee.ethz.ch/~boschie/draft-boschi-ipfix-anon-03.txt Unknown speaker: is anonymization specific to the receiving client that is using data? Brian: In general, yes. but might have arrangement; not tell anyone getting, nor distribute or freely distributable. looking at it, not addressed Unknown speaker: Sometimes we need the opposite, not anonymization but more detailed information for debugging and attack detection. I hope you anonymization will not make these actions impossible. Brian: Anonymization has special use cases. For some others it might not be preferable. Atsushi: I read version read -02. I think it is in very good shape, and the document is good to understand even without prior knowledge of anonymization. However, I would like to see an applicability section Brian: OK. Juergen: I also would like to see how to apply this function in different scenario, on a router, at a mediator, together with aggregation, etc. Juergen: And please synchronize with Tanja's draft when showing how both fit into the mediator framework. c) Handling Structured Data (Benoit Claise) draft-claise-structured-data-in-ipfix-00.txt Juergen: We heard two suggestions to fill in the mediation framework. The next presentation is different. It makes a suggestion to extend IPFIX. This is of general interest and Benoit will give a related presentation in the OPSAREA session today. Benoit presented the slides jurgen: work recursively? yes, but is open issue in draft. because wnat to clearly specify. subTemplateMultiList next steps. want some feedback. have some on ML already. welcome some more feedback. but starts to change want to do with ipfix reason why want to talk to opsarea. ipfix as generic export mechanism. open issues circular refs? usage guidelines. can model structure in multiple ways. feedback-concerns-flame? Unknown speaker: Can it represent sparse arrays efficiently? Benoit: I have to think about it. Dan: This looks like a conceptual change for IPFIX. You add a level of complexity and change the architecture of exporters. Please investigate the effect on IPFIX deployments. How would the migraqtion plan look like? You need to get feedback from folks the OPSAREA people. I don't see what this IPFIX extension would bring compared to existing solutions like SNMP notifications, file transfer, netconf notifications. My initial reaction would be to discourage you. Benoit: I think that the Internet moving in directon of application assurance. Then need flow measurements. And we need to report this on a high frequency. We will implement this at Cisco. Steve Campbell: I'm a big fan of this. As a collector company, we are already implementing this in our devices for mediation. It saves a bunch of bandwdith and it allows us to do structured list for interfaces, timestames. This stuff is relevant and makes IPFIX much more useful. Andy Bierman: When mention in slides thinks like traceroute info, ACLs, things sounded like standard monitoring information. This might be sensible information and need proper protection. Benoit: I have been looking for a good way to export ACL for a long time and could not find it. Dan: So far, IPFIX had an security model customized for flow information. If you report other things, this needs to be checked much more critically as it was necessary so far. Juergen: This document delivers a problem and soolution at once. If we go beyond scope fo flow export, we need to dicuss what is the need of the applications. At this time it is not clear to me what is the concrete need and if your soution meets their requirements. Benoit: I don't want to go for the cycle of requirements, framework, protocol again. IPFIX took so much time. I want to keep it simple. If security review limits aplicability, this would be fine with me. Al Morton: In the BMWG session on Thursday we will have a draft on IPFIX benchmarking. Please have a look at it. Juergen: Please announce it on the IPFIX mailing list.