Current Meeting Report
Slides


2.4.7 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/23/2002

Chair(s):
Nevil Brownlee <n.brownlee@auckland.ac.nz>
Dave Plonka <plonka@doit.wisc.edu>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: ipfix@net.doit.wisc.edu
To Subscribe: majordomo@net.doit.wisc.edu
In Body: subscribe ipfix
Archive: http://ipfx.doit.wisc.edu/list/ipfix/archive/
Description of Working Group:
There are a number of IP flow information export systems in common use. These systems differ significantly, even though some have adopted a common transport mechanism; such differences make it difficult to develop generalised flow analysis tools. As such, there is a need in industry and the Internet research community for IP devices such as routers to export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as Internet research, measurement, accounting, and billing.

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.

Goals and Milestones:
Done  Submit Revised Internet-Draft on IP Flow Export Requirements
FEB 02  Submit IPFX-REQUIREMENTS to IESG for publication as an Informational RFC
Done  Submit Internet-Draft on IP Flow Export Architecture
Done  Submit Internet-Draft on IP Flow Export Data Model
MAY 02  Submit IPFX-DATAMODEL to IESG for publication as an Informational RFC
MAY 02  Submit IPFX-ARCHITECTURE to IESG for publication, Proposed Standard RFC (also need an Applicability Statement RFC)
Internet-Drafts:
  • - draft-ietf-ipfix-reqs-04.txt
  • - draft-ietf-ipfix-architecture-02.txt
  • - draft-ietf-ipfix-data-00.txt
    • No Request For Comments

    Current Meeting Report
    DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
    IETF 54, Yokohama, Monday July 15, 2002
    83 people in attendance

    Reported by Dave Plonka & Nevil Brownlee (co-chairs)

    The meeting agenda is available here:

    http://ipfix.doit.wisc.edu/IETF54/IETF54_IPFIX_agenda.sdd
    http://ipfix.doit.wisc.edu/IETF54/IETF54_IPFIX_agenda.ppt

    as well as the slideshows here:

    http://ipfix.doit.wisc.edu/IETF54/

    1) Nevil gave an overview of the WG charter and current status.
    In summary, we're proceeding with the protocol evaluations.
    When these are complete we will revise the architecture and data
    model documents to embody the chosen protocol.

    2) We reviewed the current WG drafts:

    a) Requirements (see accompanying slides)
    Juergen Quittek

    Regarding multicast traffic, the current draft says only that
    a compliant protocol MAY report the set of egress interfaces
    and/or the "replication factor". It was suggested that this
    be changed to either SHOULD.

    It was observed that it would be "hard" to report multicast
    egress interfaces given some current router implementations.
    However, consensus by a hum was that a protocol SHOULD support
    these metrics.

    The next revision will be published ASAP and put to WG last
    call on the mailing list.

    b) Architecture (see accompanying slides)
    Nevil Brownlee

    c) Data Model - no changes
    Nevil Brownlee

    d) Applicability (see accompanying slides)
    Tanja Zseby

    Others were encouraged to submit text for additional sections
    of this document.

    3) Nevil reported the status of the protocol evaluation. This
    information was posted to the mailing list on 7-JUL-2002:

    http://ipfix.doit.wisc.edu/archive/1000.html

    Nevil explained that the advocacy drafts will be submitted to the
    evaluation team and will subsequently be submitted as Internet
    Drafts. (These drafts are short-lived, working group documents
    only - not to become RFCs.)

    Discussion regarding the candidate protocols is encouraged by
    all and should take place on the public mailing list using the
    "ipfix-eval@net.doit.wisc.edu" address. This will be the official
    method to communicate with the evaluation team and/or protocol
    advocates.

    Regarding the proposed deadline for advocates to submit initial
    advocacy drafts, it was suggested to change the date to 2-SEP-2002,
    to which there were no objections by those in attendance.

    Three attendees indicated that they intended to advocate specific
    protocols, namely: CRANE, DIAMETER, and NetFlow v9. Other protocols
    may be forthcoming, perhaps by advocates not in attendance.

    Lastly, the chairs will review the WG milestones and discuss them
    with with the Area Directors.

    --
    $Id: minutes.txt,v 1.1 2002/07/15 12:36:34 dplonka Exp $

    Slides

    Agenda
    IPFIX Requirements
    Architecture Draft: Changes in -02.txt
    IPFIX Applicability
    IPFIX evaluation process