Re: [ipfix] IPFIX followup charter

[Benoit Claise <[e-mail]>]

Juergen and all,

Thanks for proposing a new charter. I agree that there are a lot of 
activities and interest around IPFIX, and that a new charter is suitable.

1. The implementation guidelines draft is a must in this new charter. 
Note that I gave a long list of issues regarding this draft, and that I 
don't think its status is close to completion yet.
Regarding the per packet draft, I think the right choice to do is to 
make this concept generic, as discussed already. As a consequence, I 
would see its content as a new section in the implementation guideline 
draft, called something such as "implementation choice for the reduction 
of export". Anyway, I really consider the concepts behind the per-packet 
info as implementation guideline!
If we combine those two drafts, we can kill one bird with half a stone 
:) (private joke)

2. The flow aggregation is interesting. I must admit that I haven't 
spent a great of deal of time reviewing it though.

3. If we take the initial idea to have 3 work items in the WG charter, 
I'm wondering which one to take next. I tend to think that only looking 
at the current maturity of the drafts might not be appropriate, as 
opposed to ask ourselves the question: do we solve the right issue in 
this new charter?
Next to the IPFIX transport issue, the second highest amount of emails 
generated on the list concerned "IPFIX for billing"
I sketched a few initial ideas in 
draft-bclaise-ipfix-reliability-00.txt. I agree so that we're missing 
some meat at this point, but a second draft version will be posted 
before Dallas. So my vote would go for this work: not because I'm the 
author, but because this is an important item to solve.

Note: I'm personally not convinced by the bi-flow draft. I browsed 
through the bi-flow draft, and had some non-trivial concerns.

Regards, Benoit.

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