Subject: [ipfix] DRAFT IPFIX WG minutes, IETF52

From: Dave Plonka <[email-masked]>
Date: Thu, 13 Dec 2001 12:03:58 -0600

IPFIX folks,

Please review the DRAFT minutes of yesterday's meeting, below.
Please send any comments/suggestions/corrections to the list.

Thanks,
Dave

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

DRAFT minutes of the IP Flow Information eXport (IPFIX) WG, held at
IETF 52, Wednesday 12 December 2002, 95 people attending.

Notes by Cyndi Mills (scribe), Dave Plonka & Nevil Brownlee (co-chairs)

Dave Plonka introduced the session by reviewing the agenda:

  * Adminstrivia, Intro, Agenda bashing
  * Requirements Document
  * New (individual) drafts relating to IPFIX
  * Getting Started on IPFIX Architecture & Data Model I-Ds
  * Other material relevant to IPFIX

One item was added: "review IPFIX deliverables".

Nevil gave a brief overview of the purpose of IPFIX.

1) Juergen Quittek reviewed the state of the Requirements document.
The following topics were addressed:

 * the flow definition was modified slightly

 * addition of a "Terminology" section, which defines the following
   terms: export, collector, record, observation point, in-band/out-of-band

 * It was asked whether or not IPFIX' focus was solely to define the
   record and transport, or whether it would deal with the measurement
   techniques involved as well.  This issue was revisited a number of
   times during the meeting, and is unresolved at this point.

   We were reminded that this group was chartered to standardize
   existing practice, and that specifying new measurement techniques is
   out of scope.

 * "network surveillance" was removed from the list of target applications

 * remarks about "overload" behavior including dynamic timeouts,
   dynamic flow rules, or measurement shutdown.  We considered whether
   or not the requirements should define what the flow-exporter must or
   should do when resource limits are hit.

 * the document was changed slightly to specify that flows must be able
   to be distinguish by the input and/or output interface pair, rather
   than, necessarily, by both of them

 * unidirectional vs. bidirection flow definition
   
   Currently the Requirements document allows either.

   A number of arguments for each were expressed for each, and it was
   noted that both methodologies are used in existing practice and
   products.  Due to time constraints we will continue this discussion
   in the mailing list.

 * It was noted that data tranfer should be "congestion friendly"
   (rather than "congestion aware").  TCP was mentioned to be a
   candidate for transport.
   
 * It was suggested that the Requirements document address "reliability".

 * Juergen expects to have the next draft ready in January.

2) Kevin Zhang presented his updates to the CRANE Internet Draft.

   field padding and alignment requirements were specified, new query
   messages server to client for protocol version negotiation

   This Internet Draft is intended to be submitted for publication as
   an Information RFC in Q1 2002.

3) We considered how best to get working on our upcoming milestone
   Internet Draft documents.

   The chairs proposed the possibility of having either (1) document
   "design teams" of authors or (2) "focus groups" in particular topics
   of expertise along with document editors.

   Consensus was that design teams are preferred.

   The design team's first task is to provide an outline for the
   document, which would be a framework in which folks with specific
   areas of expertise could participate.

   Architecture

      It was suggested that the architecture investigation drive the
      determination of what pieces are most important to address.

   Data Model

      Discussion begain with this assertion:

      "Flow attributes" include "packet properties" and "subsidiary
      information" indicating the packet treament and/or network
      element state.

      There was some confusion as to what belongs in the data model.

      [Note: the chairs ask the data model design team to clarify this.
             Please consider this definition as a starting point:
	     The Data Model consists of data objects and structure to
	     be exported and the record layouts used in their transfer.]

   Twelve people volunteered to participate in the authoring of these
   two documents (either one the other or both).

4) We reviewed the WG milestones.

   The Requirements document is scheduled to go to WG last call before
   IETF53.

   The Architecture and Data Model Internet Drafts are also scheduled
   to have their first versions prepared before that next meeting.

5) * The Internet Draft, "A Framework for Passive Packet Measurement",
     was not presented.  The chairs recommended reading the document.

   * "Cisco's Future Plans for NetFlow: Version 9"
     Will Eatherton and Vamsi Valluri.

     This was a report on a template-based data tranfer format.  It is
     work-in-progress that is being prepared as an Internet Draft, to
     be ready in about two months.

     It was asked how a collector would know whether or not the same
     packets or bytes were being reported in more than one flow record
     (e.g. using a different template).  It was agreed that this is
     illustrative of why IPFIX might need to define more than simply
     data formats and transport.

   * "Scalability Analysis of Flow Export Using TCP from a Router"
     Ganesh Sadasivan.

     This was a report on the potential implications of using TCP to
     transport NetFlow v5-like flow records from high capacity routers
     with relatively high link utilizations.

After the meeting the following people volunteered:

   A D  (A=Architecture, D=Data Model)
   - -  
   X    Carter Bullard
   X X  Paul Calato
   X    Will Eatherton
   X X  Reinaldo Penno Filho
   X X  Ram Gopal
   X X  Simon Leinen
     X  KC Norseth
   X X  Juergen Quittek
   X X  Ganesh Sadasivan
   X X  Vamsi Valluri
   X X  Tanja Zseby
   X    Kevin Zhang

The chairs will set up mailing lists for these and any other volunteers
for the Architecture and Data Model I-Ds.

-- 
[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/