Last Modified: 2004-02-12
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 | |
Done | Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC | |
May 04 | Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC | |
May 04 | Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC | |
May 04 | Submit IPFX-INFO_DATAMODEL to IESG for publication as Informational RFC | |
May 04 | Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC |
======================================= Minutes of the IPFIX session at IETF 59 Wednesday March 3, 15:30 h - 17:30 h ======================================= Minutes taken by Ralf Wolter and Tanja Zseby ---------- 0. Session Summary The IPFIX WG discussed open issues of the protocol specification. Major issues were the required accuracy of timestamps. There seems to be agreement on having this unspecified and signaling it within an option record. A suggested extension of the definition of flows to also cover IP packet encapsulation properties was rejected. For several fields that exist in NetFlowV9 but not yet in IPFIX the WG discussed whether or not to include them in the IPFIX information model. A presentation on traffic metering at middleboxes showed that a large set of further fields is required in the information model. Document status: Two documents are already under review at the IESG. The discussion on calling the requirements document back because the security requirements are too hard is closed. The document can progress as it is. The remaining WG documents all have a deadline for completion in May. The editors estimated that this deadline will not be met, but that with two further iterations a stable version would probably be available at the next IETF meeting. ---------- 1. WG Status (Juergen Quittek) Juergen presented the list of WG documents and summarized their states. I-D draft-leinen-ipfix-eval-contrib-02.txt is a working group document although its name does not indicate it. ---------- 2.1. Requirement I-D: draft-ietf-ipfix-reqs-15.txt (Juergen) The WG discussed on whether encryption should be mandatory to implement or not. The document will not pass IESG if we would change it by weakening the security, so Jürgen proposed to leave it as is. --------- 2.2. Evaluation I-D: draft-leinen-ipfix-eval-contrib-02.txt (Simon Leinen) Simon got some feedback from the AD, so he prepared a revised draft. There are issues with status of the document, but there will be a workaround, a note about the references was added. There are still references to non-RFCs (e.g. requirements I-D) but in most cases the references are ok. [Juergen] Same problem in MIDCOM. There an evaluation documents where postponed until all references I-Ds became RFC. ---------- 3.1. Protocol Specification I-D: draft-ietf-ipfix-protocol-03.txt (Benoit Claise) Benoit described the changes from version 01 to 02 - Time synchronization - IEs for different precision - Flow records with multiple precision possible Q: [Juergen] Does a protocol implementation require support of all precisions? A: [Benoit] MUST only for microseconds (but he will double check) - Linkage with Info Model - Encoding rules - New Security section - Vendor specific information: [Juergen] There was a comment on the mailing list. FlowSet ID 2 and 3 might only be needed, and not 0 and 1 which were defined to be NetFlow compliant. Should be OK if FlowSet ID 0 and 1 are reserved for NetFlow, as the packet header already has a different version number (10) instead of the one which is used by NetFlow (9). - Metering process statistics - Option template for statistics - New proposal on mailing list from Maurizio - Editorial changes - Overview section on IPFIX docs Then he listed changes from version 02 to 03: - Terminology synchronized between protocol and architecture - Flow Expiration - Section Synchronized with architecture - Flow export vs. flow expiration - Editorial changes - Abstract and structure changed - Transport Protocol: finally agreed on SCTP MUST, TCP MAY, UDP MAY Q: [Juergen] Is an implementation compliant if it just supports PR-SCTP? A: [Benoit] MUST for PR-SCTP makes most sense, but I have to ask Nevil. A: [Nevil Brownlee (via Jabber)] I will talk to SCTP people on SCTP vs PR-SCTP. - Input is required for UDP and TCP: [Simon] volunteers to write one of these sections. Then Bemoit showed a list of 30 open issues and discussed some of them. - Exporter Time Accuracy: what if the exporter does not provide microsecond accuracy? [Simon] We should support devices with less accuracy but also export the accuracy provided by the device (option template). Precision field should be added to the template. [Simon (and others)] Support for exporters with less capabilities is needed. They can report their precision. He will send a proposal to the mailing list. - IP encapsulated packets: Benoit addressed the issue of whether limiting IPFIX to IP only or to be flexible for encapsulating protocols such as MPLS. He also roposed to also include GRE, IP-in-IP, IPv6 tunnel, MPLS, AtoM and replace "IP packets" by "packets" in the flow definition. [Juergen] feels that MPLS packets are covered by explicitly mentioning it in the requirements I-D, but AtoM is not. What about IP over Sonet, IP over lambda, SDH, etc.? Why limit to IP? The charter says we have to look for IP packets. [several] Discussion about the IP focus of the charter. Extending beyond IP would slow down the group. Even if we make it open for other protocols but make sure that everyone understands that we limit IPFIX to IP. If we limit it to IP only, there might be an issue with PSAMPs AtoM collection. [AD Bert Wijnen (via Jabber)] Don't try to boil the ocean. - Padding: currently a should for the exporting process, and a must for the collector. Proposal to have a MAY for the exporting process ---------- 3.2. Informatio Model I-D: draft-ietf-ipfix-info-03.txt (Juergen) Paul and Jeff couldn't make it, so Juergen presented. Several editorial changes were applied and the XML representation of the info model was changed. This change included replacing the representation of IPFIX protocol fields and adding an XML representation of field template and abstract data types. Juergen explained the new XML representation, which uses the xml2rfc tool from Marshall Rose. This will make the programming of IPFIX applications easy and increase safety. Juergen listed the open issues: - Datatypes: several changes applied like more precise names, Milliseconds and Nanoseconds were removed. They need to be added again. The IPDR data types were removed. Jeff wants to keep UUID, this needs to be discussed on the mailing list. - Field IDs: Some fields from NetFlowV9 should not be re-used, because they are NetFlow/Cisco specific. Still, the IDs of these fields should be reserved in order to avoid incompatibilities between IPFIX and NetFlowV9. This needs to be considered when registering fields IDs at IANA. - Some NetFlowV9 fields (like in/out packets) do not apply to an observer like a probe. How to deal with them? No comments from the room, to be solved on the mailing list. NFv9 has separate values for IPv4 and IPv6 netmask length. Sampling interval and sampling algorithm is used in NFv9 but probably not required (according to PSAMP). [Tanja,Benoit] Use the the PSAMP info model. - List of not yet used NFv9 fields: there are multiple fields defined by NFv9 which are not yet considered by IPFIX, but are candidates: engineType and engineID. [Benoit] Several line cards at one device require more granularity than the IP address. [Stewart Bryant] Engine ID and txpe are Cisco-specific. NFv9 defines 10 MPLSlabels, shall IPFIX also reserve 10 fields? [Simon] destClassOfService/ToS field should be reproted before and after writing it, maybe refer to DiffServ terminology. [Juergen] Let's sort it out on the mailing list. ---------- 4. new I-D on IPFIX implementation at middleboxes: draft-ietf-ipfix-info-03.txt (Martin Stiemerling) Refer to RFC 3234 for a definition of middleboxes. For IPFIX a clearly indication of the location of the observation point is required. An observation point in the midlebox might be ambiguous. Martin suggests to measure not within a middlebox, but outside of it with a clearly defined observation point. Still it is possible to report the effect of the middlebox on flows as 'middlebox internels. Open issues: - investigate security implications - should this become a WG draft? [Tanja] Middleboxes are not included in the applicability statement, so it should become a separate WG I-D. [Juergen] The results of the paper need to be considered in the info model by fields reporting middlebox internals, such as changed DSCP or tranlated addresses and prot numbers. [Benoit] We standardize export, we should rather not include middlebox recommendations for metering. [Emile Stephane] At least location of observation point should be included in other IPFIX document. Q: [?] Can a router that changes DSCP be a middlebox? A: [Juergen] A router in this case is a routing device with middlebox function. on this devices, the observation point must be defined relative to the middlebox function. Q: [Ralf Wolter] Do we limit IPFIX to ingress? A: [Juergen] No we don't! Conclusion: middlebox discussion to be finalized on the mailing list ---------- 5. WG Schedule Initial I-D Final I-D Deliverable Done Done IPFIX requirements Done May 04 IPFIX architecture Done May 04 IPFIX protocol Done May 04 IPFIX information model Done May 04 IPFIX applicability statement Q: [Juergen] When to finalize the architecture draft? A: [Benoit] May is too early, We will manage to have two iterations until the next IETF meeting. [Juergen] Information model will progress in parallel. [Tanja] I did not receive comments on the applicability I-D, so there is no new version. If more details are be requested, I will produce a new version. Iuggest to finish the protocol document first. Volunteers for sections on RMONMIB and TEWG relations to IPFIX are very welcome. [Benoit] Accidentally, there was no new version on the architecture. Ganesh will post one soon. -- $Id: minutes.txt,v 1.1 2004/03/29 14:42:04 dplonka Exp $ |