Re: [IPFIX] proposal for IPFIX charter update

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