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

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

Hi Brian,

Thanks for the comments.  Please find a few replies inline.

--On 11.04.2006 14:50 Uhr -0400 Brian Trammell wrote:

> Juergen and Nevil,
>
> In general, I agree with the content of the proposed charter.  Comments, and comments on comments, inline:
>
> Regards,
>
> Brian
>
>>> ==============================
>>> 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.
>>
>> 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."
>
> As the individual drafts in question presently do cover Collecting
> Processes, agreed.
>
>>>                   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)
>
> Should be "Reducing Redundancy".
>
>>> 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)
>
> Should be Standards Track.

Yes, of course.

>>> 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)
>
> Should be Informational.

Fine.

>>>
>>> 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
>>
>> 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.
>
> Agreed, and agreed.
>
>> 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.
>
> 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.

There is no problem with submitting the -00 version of the WG document
ahead of the planned schedule.  But since we still have some controversial
issue left, I would prefer to be careful with milestones.

Thanks,

    Juergen

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

--
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: Brian Trammell <[email-masked]>
Date: Sun, 16 Apr 2006 16:56:09 -0400

Juergen,

Understood. Either date is fine from our point of view, but of course  
an August target is eminently easier to meet than a June one. :)

Thanks,

Brian