Re: [IPFIX] proposal for IPFIX charter update
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Juergen, Taking into account Brian's comments, that works for me. Regards, Benoit. > Hi Benoit and Brian, > > Thank you for your comments. > Here comes another update. > > 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 a set of specifications for applying the IPFIX protocol at > mediators, including new specifications for protocol issues not > envisioned by the IPFIX protocol itself. > > 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 10.10.11 15:19, "Benoit Claise"<[email protected]> wrote: > >> Hi Brian, >> >> That works for me. Thanks for the better wording. >> >> Regards, Benoit. >>> Hi, Benoit, all, >>> >>> I'm not quite happy with any of these characterizations... "extension" >>> means to me "I have to worry about this, even if I don't care about >>> Mediators". Since there is _nothing_ in medproto which would require an >>> Original Exporter to do something differently when sending to a >>> Mediator, or would require a Collector to do something differently when >>> receiving from a Mediator, AFAICT this is not the case (and should not >>> be)... >>> >>> So, how about: >>> >>> >>> a set of specifications for applying the IPFIX Protocol at Mediators, >>> including new specifications for protocol issues not envisioned by the >>> IPFIX Protocol itself. >>> >>> Regards, >>> >>> Brian >>> >>> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote: >>> >>>> Hi Juergen, >>>> >>>> It's an extension/modification of the IPFIX protocol addressing the >>>> use with mediation. >>>> I'm not too sure what is the difference between extension and >>>> modification. >>>> However, since it's based on RFC5101, I would say an extension. >>>> >>>> Regards, Benoit. >>>>> 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]> 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]> >>>>>> 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]> >>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> 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 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. >>>>>>>>>>> >>>>>>>>>>> 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 the MIB modules. >>>>>>>>>>> >>>>>>>>>>> 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]://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>>> _______________________________________________ >>>>>>>>>> IPFIX mailing list >>>>>>>>>> >>>>>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>> _______________________________________________ >>>>>>>>> IPFIX mailing list >>>>>>>>> >>>>>>>>> [email protected]://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]://www.ietf.org/mailman/listinfo/ipfix >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>> >>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix >>>> _______________________________________________ >>>> IPFIX mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> > > _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix