Subject: Re: [ipfix] IPFIX followup charter

From: Falko Dressler <[email-masked]>
Date: Fri, 03 Feb 2006 09:31:16 +0100

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

-- 
Dr.-Ing. Falko Dressler
Computer Networks and Communication Systems
University of Erlangen-Nuremberg, Germany
Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409
EMail: [email-masked] / [email-masked]
WWW: http://www7.informatik.uni-erlangen.de/~dressler/

--
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: Benoit Claise <[email-masked]>
Date: Mon, 13 Feb 2006 09:56:26 +0100

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.

> IPFIX has completed its charter and PSAMP will do so very soon.  
> Still, there
> Each of 1.-3. has been presented at IPFIX or PSAMP sessions already 
> two times
>    the optimization to packet reports only. At the last PSAMP meeting 
> it was
>  - The implementation guidelines are considered the most important 
> work item
>    IPFIX and several recommendations were identified at the first 
> IPFIX interop
>    My problem with this item is that the current individual draft is 
> in a bad
> bidirectional flows.  Both have been requested on the IPFIX mailing 
> list several
> A problem of these issues is that so far they have not been presented 
> at IPFIX
> followed by the existing drafts.  Therefore, these two are not 
> included in the
> draft proposal below.
>
>
> Mar 2006  IPFIX and PSAMP interoperability testing event (not a real 
> WG milestone?)

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 14 Feb 2006 16:51:26 +0100

Benoit,

I agree that IPFIX reliability is an important issue for IPFIX
And I agree as well with others that bi-flow reporting is important.
However, we do not have discussed these issues yet on the mailing
list or in IPFIX (or PSAMP) sessions.

Therefore I would suggest handling these issues similarly to the way
it is done in the RADEXT, DHC, and other WGs.  There, new issues are
handled as individual drafts and included in the charter when they are
mature enough and often already ready for WG last call.  I think we
can proceed in this way with the two mentioned issues.

We can discuss them on the list at each meeting (monitoirng also the
progress that is made). Then we can include them in the charter as soon
as we sense sufficient stability and/or a broad support by the WG
for working on the issues.

Please find further comments inline.

--On 2/13/06 9:56 AM +0100 Benoit Claise wrote:

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

I see your point.  However, the redundancy reduction might prove to have sufficient
substance for covering it in a separate document.  Also, the reduction of redundancy
is on a higher level than most of the guidelines to be covered by the other document.
So there are good reasons for both alternatives.

Are there further opinions?

Thanks,

    Juergen

> 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,
>
> IPFIX has completed its charter and PSAMP will do so very soon.  Still, there
> 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
>    metering probe does not have the standard (Netflow default) configuration,
>    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
>    received very well by both WGs when past versions of the IDs were presented.
>    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,
>  - 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
>    My problem with this item is that the current individual draft is in a bad
> 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,
> A problem of these issues is that so far they have not been presented at IPFIX
> followed by the existing drafts.  Therefore, these two are not included in the
> draft proposal below.
>
>
> Mar 2006  IPFIX and PSAMP interoperability testing event (not a real WG milestone?)

---

From: Elisa Boschi <[email-masked]>
Date: Tue, 14 Feb 2006 17:58:48 +0100

Juergen, Benoit,

>> 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.
>> 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!

I don't think that the redundancy reduction draft should be included in
the guidelines.
I agree with Jürgen that the redundancy reduction draft is on a higher
level then the implementation guidelines and I think that this is a good
reason to keep them separate . Its content is also more "mature" than
the guidelines: while we still need to make the concept described in the
per packet draft generic, which we are doing right now, the way to go is
basically agreed on. Another thought is that merging two drafts into one
is not always the faster way to complete them. I'd rather prefer keeping
the two issues into two separate drafts.

cheers,
Elisa

>> 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
>> Next to the IPFIX transport issue, the second highest amount of
>> emails generated on the list concerned "IPFIX for billing"
>> author, but