Re: [IPFIX] proposal for IPFIX charter update

Juergen Quittek <[email protected]> Sat, 8 Oct 2011 17:23:42 +0000

Newsgroups	gmane.ietf.ipfix
Message-ID	<CAB63519.22E09%[email protected]>

Dear Benoit,

I am sorry for missing your comment. The point you are raising addresses the nature of the mediation protocol draft. Is it
- a guideline how to use the IPFIX protocol for use with mediation?
- is it an modification of the IPFIX protocol addressing the use with mediation?
- is it an extension of the IPFIX protocol addressing the use with mediation?
- is it a new protocol?

I think the text that you are proposing comes closer to what the draft does. However, I would like to have the question above answered clearly before finalizing the charter update.

Thanks,

Juergen

On 03.10.11 23:38, "Ben Claise" <[email protected]<mailto:[email protected]>> wrote:

Juergen,

One comment that was forgotten.
See inline.

Dear all,

Below please find an update of the proposed IPFIX charter update.
It addresses all comments posted on the list.
The only major change is adding item 7 on link layer IEs.

Please send you comments on this version until next Monday, Oct 10.

Thanks,

Juergen

IP Flow Information Export (ipfix)

Description of Working Group

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). Several implementers have already built
applications using the IPFIX protocol. As a result of a series of IPFIX
interoperability testing events the WG has produced guidelines for IPFIX
implementation and testing as well as recommendations for handling
special cases such as bidirectional flow reporting and reducing
redundancy in flow records.

The IPFIX WG has developed a mediation framework, that defines IPFIX
mediators for processing flow records for various purposes including
aggregation, anonymization, etc. For configuring IPFIX devices, a YANG
module has been developed.

1. Having a solid standardized base for IPFIX deployment and operation
and several existing implementations, the IPFIX WG will revisit the
IPFIX protocol specifications (RFC 5101) and the IPFIX information
element specification (RFC 5102) in order to advance them to draft
standard.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide guidelines to developers of new IPFIX information
elements and for better defining the process of registering new
information elements at IANA the IPFIX WG will create an information
element developers guideline document.

3. The export of IPFIX flow records from IPFIX mediators introduces a
set of potential issues at the protocol level, such as the loss of
information on the original exporter, loss of base time information,
loss of original options template information, etc. The IPFIX WG will
define common ways to deal with these issues, by specifying guidelines
for the use of the IPFIX protocol on IPFIX mediators.

Here is the comment I made earlier in this email thread:
"common ways", "specifying guidelines for the use of the IPFIX protocol": actually it's a real protocol specification, which will be standard track.
Should we be more specific?
Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title is: Specification of the Protocol for IPFIX Mediations

For example:

3. The export of IPFIX flow records from IPFIX mediators introduces a
set of potential issues at the protocol level, such as the loss of
information on the original exporter, loss of base time information,
loss of original options template information, etc. The IPFIX WG will
produce the protocol specifications in order to solve these IPFIX mediation
specific problems.

Regards, Benoit.

4.In order to support the aggregation of flow records at IPFIX mediators
the IPFIX WG will define how to export aggregated flow information using
IPFIX. An aggregated flow is essentially an IPFIX flow representing
packets from multiple original Flows sharing some set of common properties.
5. The IPFIX WG will investigate the use of the IPFIX protocol for
exporting MIB objects, avoiding the need to define new IPFIX information
elements for existing management information base objects that are
already fully specified. This method requires the specification of new
template set and options template sets to allow the export of MIB objects
along with IPFIX information elements.

6. The IPFIX MIB module (RFC 5815) defined a way to register packet
selector functions at IANA. The WG agreed that another method would
be preferable that requires a minor change of RFC 5815. The IPFIX WG
will produce a new version of RFC 5815 with small modifications of
the IANA actions and DESCRIPTION clauses in the MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.

Oct 2011 Publish Internet-Draftt on guidelines for IE doctors
Oct 2011 Publish Internet-Draft on IPFIX use at mediators
Oct 2011 Publish Internet-Draft on intermediate aggregation
Oct 2011 Publish Internet-Draft on exporting MIB objects
Oct 2011 Publish Internet-Draft on data link IEs
Oct 2011 Publish Internet-Draft on revised IPFIX MIB
Dec 2011 Publish Internet-Draft revising RFC 5101
Dec 2011 Publish Internet-Draft revising RFC 5102

Apr 2012 Submit guidelines for IE doctors for publication as
Informational BCP RFC
Apr 2012 Submit IPFIX use at mediators for publication as
Standards track RFC
Apr 2012 Submit intermediate aggregation for publication as
Standards track RFC
Apr 2012 Submit data link IEs for publication as
Standards track RFC
Apr 2012 Submit revised RFC 5101 for publication as
Standards track RFC
Apr 2012 Submit revised IPFIX MIB for publications as
Standards track RFC
Apr 2012 Submit revised RFC 5102 for publication as
Standards track RFC
Sep 2012 Submit export of MIB objects for publication as
Standards track RFC

On 30.09.11 09:18, "Juergen Quittek" <[email protected]><mailto:[email protected]> wrote:

Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

Juergen

On 30.09.11 00:10, "Nevil Brownlee" <[email protected]><mailto:[email protected]> wrote:

Hi all:

Juergen posted the proposed new IPFIX charter at the end of August.
I've only seen one comment on it, which was "what happened to the
Link Layer IEs draft?"

Looking at the minutes from our meeting in Quebec, we said
"We discussed whether this could be a 'trial run for the
IE Doctors,' or a WG item. We reached consensus for it as a WG item,
with the proviso that it will need views from Layer 2 domain experts,
e.g. IEEE 802.1."

So Juergen, please add this as one more charter item.

With that, I think we're ready to ask Dan to take it to IESG for
approval.

Cheers, Nevil

PS: it's really good to see lots of discussion on the IPFIX list
about improvements to 5101 et al :-)

On 29/09/11 2:40 AM, Benoit Claise wrote:

IPFIX chairs,

Hi Juergen,

The IPFIX configuration data model is pending because of the IPFIX and
PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
priority, and a solution be published before any other new draft.

I agree.

Btw, where is the new charter? ;-) There is always a tendency to delay
work for which there is no deadlines...

Regards, Benoit.

(I already see IPFIX config being outdated by RFC5101/5102bis before
it ever becomes RFC...)

Regards,
Gerhard

On 29.08.2011 06:57, Juergen Quittek wrote:

Dear all,

At our session in Quebec we discussed candidates
for new IPFIX work items. Based on this discussion,
Nevil and I drafted an update of our charter that
you can find below.

Please have a look at it and send us your comments.

Thanks,

Juergen

IP Flow Information Export (ipfix)

Description of Working Group

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). Several implementers have already built
applications using the IPFIX protocol. As a result of a series of
IPFIX
interoperability testing events the WG has produced guidelines for
IPFIX
implementation and testing as well as recommendations for handling
special cases such as bidirectional flow reporting and reducing
redundancy in flow records.

1. Having a solid standardized base for IPFIX deployment and
operation
and several exiting implementations, the IPFIX WG will revisit the
IPFIX
protocol specifications (RFC 5101) and the IPFIX information element
specification (RFC 5102) in order to advance them to draft standard.

2. For giving guidelines to developers of new IPFIX information
elements and for better defining the process of registering new
information elements at IANA the IPFIX WG will create an information
element developers guideline document.

3. The export of IPFIX flow records from IPFIX mediators introduces a
set of potential issues at the protocol level, such as the loss of
information on the original exporter, loss of base time information,
loss of original options template information, etc. The IPFIX WG will
define common ways to deal with these issues, by specifying
guidelines
for the use of the IPFIX protocol on IPFIX mediators.

4. For supporting the aggregation of flow records at IPFIX mediators
the IPFIX WG will define how to export aggregated flow information
using
IPFIX. An aggregated flow is essentially an IPFIX flow representing
packets from multiple original Flows sharing some set of common
properties.

5. The IPFIX WG will investigate the use of the IPFIX protocol for
exporting
MIB objects, avoiding the need to define new IPFIX information
elements
for existing management information base objects that are already
fully
specified. This method requires the specification of new template set
and options template sets to allow the export of MIB objects along
with IPFIX information elements.

Oct 2011 Publish draft on guidelines for IE doctors
Oct 2011 Publish draft on IPFIX use at mediators
Oct 2011 Publish draft on intermediate aggregation
Oct 2011 Publish draft on exporting MIB objects
Oct 2011 Publish draft on data link IEs
Dec 2011 Publish draft revising RFC 5101
Dec 2011 Publish draft revising RFC 5102

Apr 2012 Submit guidelines for IE doctors for publication as
Informational BCP RFC
Apr 2012 Submit draft on IPFIX use at mediators for publication as
Standards track RFC
Apr 2012 Submit draft on intermediate aggregation for publication as
Standards track RFC
Apr 2012 Submit draft on data link IEs for publication as Standards
track RFC
Apr 2012 Submit draft revising RFC 5101 for publication as Standards
track RFC
Apr 2012 Submit draft revising RFC 5102 for publication as Standards
track RFC
Sep 2012 Submit draft on exporting MIB objects for publication as
Standards track RFC

_______________________________________________
IPFIX mailing list
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/ipfix

--
---------------------------------------------------------------------
Nevil Brownlee Computer Science Department | ITS
Phone: +64 9 373 7599 x88941 The University of Auckland
FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
IPFIX mailing list
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix