Subject: [ipfix] Proposed new charter for IPFIX (version 01)

From: Nevil Brownlee <[email-masked]>
Date: Sun, 9 Apr 2006 22:03:34 +1200

Hi all:

We've now had discussion of 'new IPFIX work items' on the list for
about two weeks, with strong support for the Implementation Guide,
Testing and Redundancy drafts, and clearly expressed support for the
IPFIX MIB and Biflows drafts.  I've taken Juergen's earlier draft
of a new IPFIX charter and reworked it to cover these five drafts.
I've also set out what I think are reasonable milestones for them.

Please read the PROPOSED new charter carefully, and send your comments
on it to the IPFIX list.  I'll revise it from time to time over the next
few weeks; I'd like to give it to our ADs for approval by IESG fairly
soon, let's say "by 30 April 06."

One other thing.  Dave Plonka intends to stand down as IPFIX co-chair;
after discussion among the current IPFIX and PSAMP co-chairs, we suggest
that Nevil Brownlee and Juergen Quittek chair the rechartered IPFIX WG.
Feedback on that (including suggestions for other possible co-chairs)
would also be welcome!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

==============================
PROPOSED new charter for IPFIX   version 01, 9 Apr 06
==============================

The IPFIX working group has specified the Information Model (to
describe IP flows) and the IPFIX protocol (to transfer IP flow data
from IPFIX exporters to collectors).  The PSAMP working group has
specified the usage of the IPFIX protocol for exporting packet
records. With both specifications available, several implementers have
started building applications using the IPFIX protocol.

At two interoperability testing events, several IPFIX protocol
implementations were tested. The experiences made at these events were
fed back to IPFIX protocol specification, particularly for removing
ambiguities.  In addition, several lessons were learned about how to
implement and use IPFIX correctly and efficiently.  The exchange among
different implementers further led to new ideas for advanced usage of
IPFIX.  Many of these ideas are currently documented in individual
Internet drafts.

The goal of the IPFIX working group is now to produce 'best current
practice' and 'guideline' documents concerning implementation,
application and usage of the IPFIX protocol.

Out of scope are modifications to the core IPFIX and PSAMP
protocol specifications.  In scope is the definition of new IPFIX
and PSAMP information elements.

Specific Goals

o Develop guidelines for implementers based on experiences
  gained individually by implementers and jointly at interoperability
  testing events.  The guidelines will give recommendations for
  integrating IPFIX observation points, measurement processes, and
  exporting processes into the packet flow at different kinds of
  IPFIX devices.  They will make suggestions for efficient
  implementation of the IPFIX protocol features and identify parts of
  the IPFIX specification that have already been misunderstood by
  several implementors.  For some implementation choices that the
  protocol specification leaves to the implementer, the guidelines will
  discuss advantages and disadvantages of the different choices.
  Several recent individual drafts call for new Information Elements;
  The implementation guidelines will explain procedures for requesting,
  reviewing and approving new IEs.
  Deliverables:  1. IPFIX Implementation Guidelines draft, to be an 
Informational RFC
       (6 months)
  2. IPFIX Testing draft, to be an Informational RFC  (6 months)

o Develop methods and means for an efficient use of the IPFIX
  protocol by reducing redundancy in flow reports.  The basic idea
  to be followed is very simple.  For multiple flow records that all
  report the same value in one or more of the contained IPFIX
  information elements, those values are removed from the flow
  records and instead reported once for all in a separate record.
  Such an approach integrates very well with the IPFIX protocol and
  only needs a few simple methods for expressing the relationship
  between flow records and corresponding separate records.
  Deliverable:
  3. IPFIX Reducing Reduncy, to be an Informational RFC  (6 months)

o Create an IPFIX MIB, for reporting information and statistics
  of IPFIX metering, exporting and collecing processes.  Much of this
  work has already been done by the PSAMP working group, and by
  individuals working on IPFIX collectors.   Deliverable:
  4. IPFIX MIB, to be an Informational RFC (12 months)

o Develop an effective method for exporting information about
  bidirectional flows ('biflows').  The IP security community has
  expressed a strong need to collect data on bidrectional flows.
  A recent individual draft discusses several different ways to
  support biflows in IPFIX - this work will produce a single,
  best-practice method for handling them, without requiring changes
  to the IPFIX protocol.
  Deliverable:
  5. IPFIX Biflow draft, to be a Standards Track RFC (6 months)

Milestones:

August 06    Publish Internet Draft on IPFIX Implementation Guidelines

August 06    Publish Internet Draft on IPFIX Testing

August 06    Publish Internet Draft on Reducing Redundancy in IPFIX 
data transfer

August 06    Publish Internet Draft on IPFIX MIB

August 06    Publish Internet Draft on Handling IPFIX Bidirectional Flows

November 06  Submit IPFIX Implementation Guidelines draft to IESG for
             publication as Informational RFC

November 06  Submit IPFIX Testing draft to IESG for
             publication as Informational RFC

November 06  Submit IPFIX Reducing Redundancy draft to IESG for
             publication as Informational RFC

November 06  Submit IPFIX Biflows draft to IESG for
             publication as Informational RFC

March 07     Submit IPFIX MIB draft to IESG for
             publication as Standards track RFC

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

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz

--
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: Juergen Quittek <[email-masked]>
Date: Tue, 11 Apr 2006 10:39:25 +0200

Hi Nevil,

Please find two comments inline.

Thanks,

    Juergen

--On 09.04.2006 22:03 Uhr +1200 Nevil Brownlee wrote:

>   IPFIX devices.

I suggest that the guidelines should no just cover the sender of IPFIX
messages, but also the collection process on the receiver side. What about
just adding "collecting processes":
OLD
                    "The guidelines will give recommendations for
    integrating IPFIX observation points, measurement processes, and
    exporting processes into the packet flow at different kinds of
    IPFIX devices."
NEW
                    "The guidelines will give recommendations for
    integrating IPFIX observation points, measurement processes,
    exporting processes, and collecting processes into the packet
    flow at different kinds of IPFIX devices."

>                   They will make suggestions for efficient
>   Deliverables:  1. IPFIX Implementation Guidelines draft, to be an Informational RFC
>        (6 months)
> August 06    Publish Internet Draft on Reducing Redundancy in IPFIX data transfer
>

For some documents we should easily be able to have initial versions already before
the next meeting.  I suggest replacing for these three milestones "August 06" with
"June 06".  We have quite mature individual I-Ds for these three issues.

For the MIB we do not yet have an individual I-D, so August should be fine.

For the bi-flow story, we have not yet agreed on the "single, best-practice method
for handling them" and more discussion appears to be necessary for jointly selecting
one. Also here, August should be fine.

Thanks,

    Juergen

---

From: Brian Trammell <[email-masked]>
Date: Tue, 11 Apr 2006 14:50:56 -0400

Juergen and Nevil,

In general, I agree with the content of the proposed charter.  
Comments, and comments on comments, inline:

Regards,

Brian

>    flow at different kinds of IPFIX devices."

As the individual drafts in question presently do cover Collecting  
Processes, agreed.

>>   3. IPFIX Reducing Reduncy, to be an Informational RFC  (6 months)

Should be "Reducing Redundancy".

>>   4. IPFIX MIB, to be an Informational RFC (12 months)

Should be Standards Track.

>>   5. IPFIX Biflow draft, to be a Standards Track RFC (6 months)

Should be Informational.

> For the MIB we do not yet have an individual I-D, so August should  

Agreed, and agreed.

> one. Also here, August should be fine.

For what it's worth, we were planning on attempting to resolve the  
information element assignment question with discussion over the next  
couple of months on the list, and publishing a new revision of the  
biflow draft containing this resolution to the information element  
assignment issue by June, in time for Montreal. -01 as is advances a  
single approach to single-record biflow encoding, in line with  
comments from Dallas. So, June would be acceptable, as well.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Apr 2006 21:56:03 +0100

IPFIXers,

>    flow at different kinds of IPFIX devices."

Measurement Process is a PSAMP term, and isn't used at all in IPFIX.

Section 3.10 of [psamp-framework] ("PSAMP and IPFIX Interaction") says:

       The PSAMP Measurement Process can be viewed as analogous to the
       IPFIX metering process.

We should be careful to use the right terminology.

In section 3.3.3 of the Implimentation Guidelines draft, "measurement 
processes" should be "Measurement Process" because it's an IPFIX draft.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Apr 2006 22:58:49 +0100

> processes" should be "Measurement Process" because it's an IPFIX draft.

Duh! "Metering Process".

---

From: Elisa Boschi <[email-masked]>
Date: Wed, 12 Apr 2006 14:49:58 +0200

Dear all,

> just adding "collecting processes":

yes, "collecting processes" should be added since they're addressed in
the draft

>    flow at different kinds of IPFIX devices."
agreed.
I've also corrected the Guidelines to mention just metering, and not
measurement, processes (thanks Paul!)

> "June 06".  We have quite mature individual I-Ds for these three issues.

I agree. The reducing redundancy and implementation guidelines drafts
are indeed quite mature and should be published in June.

cheers,
Elisa

---

From: kobayashi atsushi <[email-masked]>
Date: Thu, 13 Apr 2006 19:29:03 +0900

Hi all,

I agreed with new charter.
About IPFIX MIB, I would like to continue to work as far as possible.

Thanks,
Atsushi KOBAYASHI

On Sun,  9 Apr 2006 22:03:34 +1200

>   4. IPFIX MIB, to be an Informational RFC (12 months)

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 12 Apr 2006 20:21:51 +0200

>> processes" should be "Measurement Process" because it's an IPFIX draft.

Looks like this happens quite easily :-)

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 23:23:43 +0200

Nevil,

After reading the full thread, I agree with all the comments.
My main concern has been perfectly expressed by Juergen:

    For the bi-flow story, we have not yet agreed on the "single,
    best-practice method
    for handling them" and more discussion appears to be necessary for
    jointly selecting
    one.

Regards, Benoit.