Subject: [ipfix] DRAFT IPFIX WG minutes, IETF53

From: Dave Plonka <[email-masked]>
Date: Wed, 20 Mar 2002 08:54:41 -0600

IPFIX folks,
  
Please review the DRAFT minutes of the most recent meeting, below.
Please send any comments/suggestions/corrections to the list.

Thanks,
Dave

P.S.  The slide shows (and also the draft minutes) are available at:

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

----------------------------------------------------------------------

DRAFT minutes of the IP Flow Information eXport (IPFIX) WG
IETF 53, Minneapolis, Monday March 18, 2002
78 people in attendance

Reported by Greg Ruth (scribe), Dave Plonka & Nevil Brownlee (co-chairs)

The meeting agenda is available here:

   http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.sdd
   http://ipfix.doit.wisc.edu/IETF53/IETF53_IPFIX_agenda.ppt

Nevil gave a brief overview of the IPFIX goals, commenting particularly
that the working group is not trying to invent anything from scratch
and that the IPFIX system must utilize a congestion-aware transport
protocol.

Regarding the milestones, we have completed our first drafts of
architecture, requirements and data model on schedule.

Mark Fullmer of OARnet, and author of flow-tools, did a short
presentation entitled Abilene NetFlow Deployment, which the co-chairs
introduced as an example of a large-scale flow-based measurement
system.  The presentation is available at:

      http://ipfix.doit.wisc.edu/IETF53/abilene-netflow.ppt

   The measurement system currently collects about 350 million flows
   per day, and processes them using multiple kinds of analysis.

   Mark noted some security issues included that current NetFlow
   authentication is based solely on source IP.  While spoofed flows
   can be detected by sequence numbers, this is not often done in
   practice.

   Mark's tools can be found here:

      http://www.splintered.net/sw/flow-tools/

The next item on the agenda was to review the WG documents.

1. IPFIX Applicability - Tanja Zseby, FhG FOKUS

      http://ipfix.doit.wisc.edu/IETF53/IPFIX-applicability.ppt

   The chairs mentioned that while this document is not yet listed
   as a WG milestone, it will be required for making IPFIX a standard.

   Tanja noted these document objectives:
      a) show how target applications can use IPFIX;
      b) describe relations and potential interfaces to other
	 frameworks/working groups (RTFM, IPPM, AAA, etc.)
      c) the document is expected to address at least these applications:
	 Accounting, traffic profiling, TE, Intrusion detection,
	 QoS Monitoring, Deployment of Sampling in IPFIX

   The document is available here and will be published as an Internet
   Draft soon:

      http://ipfix.doit.wisc.edu/app/ipfix-applicability-v1.txt

2. IPFIX Requirements - Juergen Quittek, NEC

      http://ipfix.doit.wisc.edu/IETF53/IPFIX-reqs-IETF53.ppt

   Juergen mentioned the following updates:

   a) added section 2 on terminology - IP traffic flows, observation
      point, metering process, flow record, exporting process,
      collecting process
   b) replaced "measuring device" by either "metering process",
      "export process" or "IPFIX device" as appropriate
   c) removed "network surveillance" section
   d) added "overload behavior" section

   There are some changes that need to be done for the next (and
   probably final) draft:  consistency checks, add "observation
   domain", remove "IPFIX device", rephrase Security Considerations

   Next version to appear May 1 - expect WG last call at that time

3. IPFIX Information Model (formerly Data Model) - K.C. Norseth

      http://ipfix.doit.wisc.edu/IETF53/ipfix_data_ietf53.ppt

   KC's overview consisted of the following points:

      a) This document was created by a design team: equipment vendors,
         applications vendors and users
      b) flow types and flow definitions
      c) selection criteria for a flow
      d) packet encoding format
      e) information elements

   Outstanding issues include:

      a) need to clarify more elements
      b) counters (absolute vs. Delta - may have both)
      c) source & destination address types

   Next steps are:

      a) complete/refine the flow definition
      b) add missing information elements
      c) detailed definition of elements (type, size, detailed description)

   Discussion:

   Should we have just one document instead of a info/data model and
   architecture (??)

      Consesus was that it was reasonable to have one seperate document
      listing the information elements, which may need to be updated
      more often than the architecture document.

   Should some topics be moved out of the data model (back) into the
   architecture document?

      As the data model document matures, we may revisit whether the
      defintion of the flow belongs in this document or in the
      architecture document.

4. IPFIX Architecture - KC Norseth

      http://ipfix.doit.wisc.edu/IETF53/ipfix_arch_ietf53.ppt

   The architecture document was also developed by the design team.

   KC presented an overview of the elements of an architecture
   including: collector, IPFIX device, etc.

   The IPFIX Protocol as implemented in the exporting device will
   encode the control information into  self-describing structures,
   encode the flows measured, and packetize the flow records.  It will
   use the underlying transport layer to send the export packets to the
   collector.

   The IPFIX Protocol in the collecting device will receive and store
   the control information, decode and store flow records using the
   control information.

   The architecture document currently refers to separate control and
   data streams.  The control stream being a reliable path to exchange
   control information, monitor connectivity and other failures, and
   the data stream to send the IPFIX export payload itself.

   At this point, a number of attendees took issue with the use of the
   word "control" because it can be confusing.  In response it was
   noted that, in this context, "control [information]" refers to the
   portion of IPFIX which communicates the structure of the exported
   data.

   Consensus was that both the words "control" and "stream" are
   inappropriate.  "Data description" was suggested as an alternative.

   [Note that the architure document currently contains a section on
    "Selection Criteria" for the IPFIX application-level protocol.
    This section will ultimately be replaced by one describing
    the IPFIX protocol, as the result of the selection process
    (see below).]

   KC mentioned that the co-chairs said that all the references to UDP
   as transport must be removed from the architecture document.

   This triggered a discussion about transport protocols.

   The result of that was that it is IETF consensus (RFC 2914), not
   just an IESG policy, that standard protocols must use
   congestion-aware transport.

   The proposed DCP transport protocol may be satisfactory (since it
   accommodates congestion handling).  The transport area director
   noted that good implementations of TCP and SCTP should be perfectly
   satisfactory for our purposes at this time.

   It was asked what "reliability" means for the IPFIX
   application-level protocol.  In response, it was noted that IPFIX's
   reliability requirement isn't necessarily satisfied by simply using
   a reliable transport protocol.  Reliability is a multifaceted
   issue.  Different degrees of reliability for different kinds of
   records.

   It was suggested that IPFIX consider the Reliable Server Pooling
   WG effort and its documents:
      http://www.ietf.org/html.charters/rserpool-charter.html

   Regarding capability negotiation, consensus amongst attendees (by a
   hum) was that neither exporter configuration nor capabilities
   negotiation between collectors and exporters should not be addressed
   by IPFIX.  The chairs will follow-up with a call on the mailing
   list on this topic.

   Also, the chairs said that explicit references to template-based
   application-level protocols need to be removed from the architecture
   document, since the IPFIX requirements do not exclude other
   candidate self-describing data encoding methods.

The chairs turned the discussion to WG process issues, specifically
they proposed an evaluation and selection process for the IPFIX
application-level protocol.

The proposal is that we will have an "evaluation team" consisting of
an odd number of people having experience in disciplines including
router hardware, probes, application software, and end use of
flow-based measurements.  The chairs will select the members from
among the interested respondents.

The evaluation team will consider candidate protocols which (a) have
a working implementation, (b) are documented by an Internet Draft
or RFC, and (c) have a IPFIX participant advocating the selection of
that protocol and willing to produce a brief document, such as an I-D,
explaining how the protocol meets the selection criteria.

The evaluation team will interact with the advocates by responding
to the advocacy documents with lists of issues/deficiencies and may
ask additional questions of the advocates.  They will also produce
a report according within a WG-defined timeframe proposing their
selection and identifying suggested improvements as necessary.

The evaluation report will be discussed and approved by mailing
list consensus.

Subsequent discussion did not offer any improvements to the proposed
process.

In reponse to a question about whether multiple IPFIX application
protocols could be selected, the chairs said that the goal is to settle
on a single protocol and that protocols unencumbered by intellectual
property issues will be preferred.

Lastly, WG milestones were reviewed.  The editors of each document
agreed to produce their next revision by May 1.

The chairs plan to solicit for candidate protocol advocates and appoint
an evaluation team by May 1, and call for advocacy reports by June 1.
The evaluation team will present a status report at the next IETF WG
meeting in July.

--
$Id: minutes.txt,v 1.1 2002/03/20 14:36:33 dplonka Exp $

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: [email-masked]
Date: Wed, 20 Mar 2002 07:44:59 -0800 (PST)

>   negotiation between collectors and exporters should not be addressed
                                      delete this 'not' ^^^                   
>   by IPFIX.  The chairs will follow-up with a call on the mailing

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand