Re: [ipfix] IPFIX followup charter

[Falko Dressler <[e-mail]>]

Dear Juergen, Tanja, Brian, Carter, *,

I read all the responses to Juergens initial email. Mostly, they
suggested to include "just another" additional item to the proposed
charter. I believe that all these proposals are really important to
successfully deploy IPFIX in the field or to convince a wider audience.
Nevertheless, I support Juergens idea of having a very short living
charter that covers only a few drafts and a quick re-chartering to
include the "next couple of" drafts - again for a fast WG processing.
This procedure does not exclude any bright ideas from the IPFIX WG but
allows to always focus on a few drafts, bringing them to RFC state, and
to repeat these steps again and again.

Cheers,
Falko.

Juergen Quittek wrote:
> Dear all,
> 
> As you know, the IPFIX working group has completed its charter
> by submitting all planned documents (with a delay of several years)
> to the IESG for publication as RFC.  Also the PSAMP WG will reach
> this status soon.
> 
> Building on the results of these WGs, there are a lot of related
> ongoing activities that are producing Internet drafts related to
> IPFIX.  Several of them have already been presented at recent IPFIX
> and PSAMP sessions.  But working on them is not covered by the IPFIX
> or PSAMP charter.  If we want to continue this IPFIX-related work,
> we need a new charter that gives it a home at the IETF.
> 
> The text below lists and discusses related work and suggests a
> charter for a follow-up WG.  It is the output of several discussions
> with Tanja, Benoit, and Nevil.
> 
> The proposed charter is very short-lived and includes only the three
> most mature work items out of a longer list of candidates.  The basic
> idea is completing this charter within less than a year and then
> re-chartering to cover further work items that have progressed until
> then.  This lean work model with short-lived charters allows the group
> to focus on a limited number of issues and is preferable to long-lived
> WGs working on many issues in parallel.  (It is highly recommended
> by the IESG.)
> 
> Please have a look at it and state whether or not you think it makes
> sense to have an IPFIX follow-up WG.  Also please read the proposed
> charter carefully and express your objections, concerns, comments,
> requests for modifications, etc.
> 
> The plan is to elaborate the new charter proposal on this list and
> submit an agreed version to our area directors soon.  The deadline
> for requesting BoF sessions at the next IETF meeting in Dallas is
> February 13.
> 
> Thanks,
> 
>    Juergen
> 
> 
> =======================================================
> Why do we need to continue the work of IPFIX and PSAMP?
> =======================================================
> 
> IPFIX has completed its charter and PSAMP will do so very soon.  Still,
> there
> are a lot of ongoing activities in the community of these two WGs:
> 
> 1. Flow aggregation
>   draft-dressler-ipfix-aggregation-01.txt
> 
> 2. reducing redundancy in IPFIX and PSAMP reports
>   draft-boschi-export-perpktinfo-00.txt
> 
> 3. IPFIX implementation guidelines
>   draft-boschi-ipfix-implementation-guidelines-00.txt
> 
> 4. Path-coupled meter configuration
>   draft-fessi-nsis-m-nslp-framework-02.txt
>   draft-dressler-nsis-metering-nslp-03.txt
>   (currently under discussion in the NSIS WG, but not covered
>   by the NSIS charter. It is a candidate work item for NSIS
>   re-chartering, but the NSIS WG asks if it would not be better
>   covered by IPFIX)
> 
> 5. IPFIX reliability
>   draft-bclaise-ipfix-reliability-00.txt
> 
> 6. Reporting bi-directional flows with IPFIX
>   draft-boschi-ipfix-biflow-01.txt
> 
> 7. a format for storing IPFIX records
>   draft-trammell-ipfix-file-00.txt
> 
> 8. IPFIX MIB module
>   no I-D yet, but two teams working on it independently.
> 
> 9. Common IPFIX templates
>   draft-stephan-isp-templates-01.txt
> 
> 10. Reliable server pooling for IPFIX
>    draft-coene-rserpool-applic-ipfix-01.txt
> 
> 11. Flow sampling
>    draft-molina-flow-selection-00.txt (expired)
> 
> Did I miss something?
> 
> 
> 1.-4. and 9. have already been discussed at past IPFIX or PSAMP sessions.
> 
> This list shows two things.
>  - There is a community interested in IPFIX that is not too small.
>  - This community and is willing to further work on issues IPFIX-related
>    issues in the IETF.
> This is a very good starting point for a charter discussion.
> 
> 
> ============================
> Which work items are suited?
> ============================
> 
> Not all of the issues listed above are at a stage, where they should be
> considered as a WG work item, but 1.-4. are quite well developed and 5.
> and 6. are candidates.  Since 4. is a candidate for NSIS re-chartering,
> I dropped it from the following considerations.
> 
> Each of 1.-3. has been presented at IPFIX or PSAMP sessions already two
> times
> with some discussion on the suggested approach.  For all I sense an
> agreement
> in the IPFIX WG (at least no objections so far) that these issues are
> relevant
> work and potential WG work items (to be confirmed on the list, of course).
> 
>  - The flow aggregation work is rather mature.  Actually this draft covers
>    something that is missing in IPFIX: How to tell the collector that the
>    metering probe does not have the standard (Netflow default)
> configuration,
>    but filters and aggregates certain flows.
>    There are some terminology problems and a set of technical issues to be
>    solved, but there is not problem with the general direction and the
> chosen
>    approach.  Still, thorough reviews are missing as well as a
> discussion on
>    how to fit it well into the IPFIX architecture.
> 
>  - Reducing redundancy in IPFIX and PSAMP reports is an issue that was
>    received very well by both WGs when past versions of the IDs were
> presented.
>    It is considered a useful method of applying IPFIX efficiently.
>    Still, the current drafts were considered as to specific.  They apply
>    the optimization to packet reports only. At the last PSAMP meeting it
> was
>    noted that the method should be generalized such that it can be
> applied to
>    all redundant IPFIX transmissions.  This generalization needs to be
> done,
>    but the way to go is clear and basically agreed on.
> 
>  - The implementation guidelines are considered the most important work
> item
>    by many WG members (including myself).  Many people are currently
> implementing
>    IPFIX and several recommendations were identified at the first IPFIX
> interop
>    (next one is scheduled for end of February).  The sooner this
> document is
>    available, the more will help improving ongoing implementations.
>    My problem with this item is that the current individual draft is in
> a bad
>    shape.  Therefore, the milestones for this item are later than for the
>    others.
> 
> The two weaker candidates for WG items are IPFIX reliability and
> reporting of
> bidirectional flows.  Both have been requested on the IPFIX mailing list
> several
> time in the past years, but we could not agree on making them part of
> the basic
> IPFIX standard.
> But as add-ons, that integrate well with the standard, they can be
> considered,
> particularly since I heard about operator requests for both of them.
> A problem of these issues is that so far they have not been presented at
> IPFIX
> or PSAMP sessions and there has not been a discussion yet on the approaches
> followed by the existing drafts.  Therefore, these two are not included
> in the
> draft proposal below.
> 
> 
> =================================
> Charter Proposal:
> Efficient Use of IPFIX (USEIPFIX)
> =================================
> 
> The IPFIX working group has specified the IPFIX protocol for exporting
> flow records. 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 a first interoperability testing event, several IPFIX protocol
> implementations were tested. The experiences made at this event 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 USEIPFIX working group is producing best current
> practice and guideline documents concerning implementation, application
> and usage of the IPFIX protocol.
> 
> Out of scope are modifications of the core IPFIX and PSAMP protocol
> specifications.  In scope is the definition of new IPFIX and PSAMP
> information elements within the documents produced by the USEIPFIX WG.
> 
> Specific Goals of the USEIPFIX WG are:
> 
> o Developing 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
>  implementers.  For some implementation choices that the protocol
>  specification leaves to the implementer, the guidelines will discuss
>  advantages and disadvantages of the different choices.
> 
> o Developing methods and means for an efficient use of the IPFIX
>  protocol that reduces 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, these 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
>  few means for expressing the relationship between flow records and
>  corresponding separate records.
> 
> o Develop a method for flow aggregation reducing the amount of
>  measurement data exchanged between IPFIX exporters and IPFIX
>  collectors.  Using aggregation techniques, measurement information of
>  multiple similar flows is aggregated into few meta-flow records.
>  Applied aggregation rules need to be communicate.
> 
> o Investigate further ways of efficiently using the IPFIX protocols
>  including but not limited to
>    - providing reliability for IPFIX transmissions,
>    - reporting bi-directional flows,
>    - path-coupled configuration of IPFIX devices,
>    - reporting the configuration of IPFIX devices,
>    - flow sampling at IPFIX devices,
>    - storing IPFIX flow records and packet records.
>  These issues are not current work items of the USEIPFIX WG but are
>  evaluated as candidates for potential future work items.
> 
> 
> Milestones:
> 
> Mar 2006  Initial version of flow aggregation methods
> Mar 2006  Initial version of reducing redundandy in IPFIX records
> Mar 2006  IPFIX and PSAMP interoperability testing event (not a real WG
> milestone?)
> Apr 2006  Initial version of implementation guidelines
> Jul 2006  Submit flow aggregation methods to IESG
> Sep 2006  Submit reducing redundancy in IPFIX records to IESG
> Sep 2006  Submit implementation guidelines to IESG
> 
> 
> -- 
> Help        mailto:[e-mail] and say "help" in message
> body
> Unsubscribe mailto:[e-mail] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

-- 
Dr.-Ing. Falko Dressler
Computer Networks and Communication Systems
University of Erlangen-Nuremberg, Germany
Phone: [phone] / Fax: [phone]
EMail: [e-mail] / [e-mail]
WWW: http://www7.informatik.uni-erlangen.de/~dressler/

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