Re: [IPFIX] New WG Last Call fordraft-ietf-ipfix-flow-selection-tech-06.txt

["Zseby, Tanja" <[e-mail]>]

Hi Brian,

thanks for summarizing the comments. Please find my answers below

> 1. As Benoit said, and in refinement of my earlier message, the model which
> the document uses should be based on an Intermediate (Flow) Selection
> Process (IFSP) as in RFC 6183, instead of adding new concepts to 5470. The
> case in section 4.1 is a bit of a special one, to address an uncommon
> requirement; in addition, it isn't really a flow selection process at all, but
> rather a packet selection process that selects packets on the same criteria
> that by which packets are separated into flows by the flow key. Therefore it
> can be noted here, I think, that the _function_ run within an IFSP can run _as
> a packet selection process_ before flow generation within an MP without
> having to hack new processes into the 5470 model. Section 6 will have to be
> updated a bit to fit this change as well.

I did not see the aggregation and classification process as contradiction to RFC 5470, just as a more detailed/fine grained view on processes that are needed inside the metering process to generate flow records from packets. I think we need this more fine grained view to describe the different flow selection processes.
We can try to align with the Intermediate Process in RFC6183, but the definition in RFC6183 requires a record stream as input which is not the case in 4.1. (as you point out) and also not the case if you apply the method on flow cache entries (which may contain different information than the final flow record). In those cases the flow selection takes place _within_ the metering process, before a record is generated. So we probably would also violate the RFC6183 definition.

> 
> 2. The document should use a different term for "aggregation" (of packets
> into flows) to avoid collision with terminology related to aggregation in RFCs
> 5982 and 6183.

Maybe we can use "packet aggregation" to make it clear?

> 
> 3. The document should use a different term for "classification" to avoid
> confusion with the use of this term with respect to "flow classification" and
> labeling. I realize 5470 uses the verb "classify" to refer to this process; I really
> wish it didn't.

I think that  both terms, aggregation and classification, are correct here to describe the processes. It is just another entity (packets instead of flows) that is classified or aggregated. So maybe we can use "packet classification " and "packet aggregation"?

> 
> Aggregation and classification _together_ comprise the "assignment" of
> packets to flows, and flow "generation". I'm afraid I don't have any better
> suggestions at this time.

This is exactly my understanding.

> 
> 4. Terminology based on terminology borrowed by analogy or reference to
> the packet selection techniques draft is a good idea; however, these terms
> should be defined in section .

To which terms do you refer to? In which section?

>  Additionally, terminology through the entire
> document should be reviewed for proper capitalization.

o.k.

> 
> 5. Within section 6, it is not clear how to apply this configuration data model.
> Should this be harmonized with ipfix-configuration-model?

Yes, it shoudl be possible to use this as basis, like PASMP-TECH. Should we just reference to the config-model or  do you suggest any further alignment?

> 
> 6. In section 7, I would suggest unifying Paul and Benoit's comments on the
> subject of fsFlowRecordTotalCount; additionally, the IE should be named
> flowDeltaCount to keep parallel with IEs 1 and 2. Consider renaming the IEs in
> general to drop the "fs" prefix. perhaps "postSelection" or something similar
> (as with the pre/post IEs). Review other IEs to ensure they are not covered
> by existing IEs (especially those "pre-selection", as with IE 3)
> 

We used fs in order to clarify that this refers to the flow records as seen as input by the selection process. The values may differ e.g. if we cascade multiple subsequent flow selection processes. 
Wrt to delta counters I am unsure. We want to have the total records for the interval that is used for the selection process. This might differ from the reporting interval. So if we use the term deltaCount it refers to the reporting interval. We need to have a further look into this.

> 7. What is a Flow Entry? Should this be defined in this document, or
> referenced as terminology from another? If this is what I think it is (reporting
> flow cache size inline), I'm not certain it belongs here in flow selection
> (perhaps in a document on metering process monitoring?).

With flow entry we mean an entry in the flow cache. We differentiate this from flow records because it may include different information than the flow record (e.g., current flow size vs. final flow size, additional counters per flow entry that are not exported, etc.).

Kind regards
Tanja

> 
> Best regards,
> 
> Brian
> 
> On May 26, 2011, at 4:20 PM, Brian Trammell wrote:
> 
> > Hi, Nevil, all,
> >
> > The following is intended as a WGLC comment on flow-selection-tech. It
> will not be my only one; however, it identifies an issue I've seen in a cursory
> review of the document which I believe could benefit from some discussion:
> >
> > Is this document intended to update RFC 5470? I'm not convinced this is
> necessary; e.g. RFC 6235 defines a flow-modifying intermediate process, and
> shows how it could be integrated into various stages within the IPFIX
> Architecture, without introducing a new model of how data is handled in the
> architecture. If each additional intermediate process definition updates the
> architecture, the architecture becomes confusing, and subsequently useless.
> >
> > If the authors and the WG believe it is necessary to update 5470 to support
> flow selection, I would _strongly_ suggest reviewing all new terminology, as
> the proposed terms collide with existing terms of art in network
> measurement. Specifically, there are two serious problems here. First, I'm
> not aware of any use of the word "classification" with respect to the
> associating of packets with flows; classification instead seems primarily to be
> used when associating a label with a packet of a flow (e.g., application
> classification). Second, while packets are indeed aggregated into flows, the
> word "aggregation" in this draft is used in a completely different way than in
> either -ipfix-a9n or in RFCs 5982 or 6183. This could lead to confusion.
> >
> > More detailed comments to follow.
> >
> > Best regards,
> >
> > Brian
> >
> > On May 24, 2011, at 11:27 PM, Nevil Brownlee wrote:
> >
> >>
> >> Hi all:
> >>
> >> Thanks very much to all the authors of the flow-selection draft, it
> >> does indeed look much better.  Since there's so much new material in
> >> it, we need to run a new WG LC on it - that start's today, and will
> >> finish on Friday, 10 June.  Do please read it anew, and send comments
> >> to the list.  Brief comments such as "yes, this looks fine now" are
> >> welcome, of course!
> >>
> >> Cheers, Nevil
> >>
> >>
> >> On 23/05/11 9:30 PM, Zseby, Tanja wrote:
> >>> Hi all,
> >>>
> >>> we worked on a major revision of the flow selection draft and just
> submitted a new version (see below). Among other changes we now provide
> a much improved classification of methods, which is more consistent with the
> PSAMP packet selection documents.
> >>> Many thanks to all who provided comments.
> >>>
> >>> Changes:
> >>> - Flow recording process removed
> >>> - Clarification of difference between flow selection and packet
> >>> selection
> >>> - Distinguished flow filtering and flow sampling similar to PSAMP
> >>> - Flow selection in the metering process either before aggregation
> >>> or after aggregation
> >>> - Integrated Flow-state dependent packet selection
> >>> - Supporting arbitrary  key space subsets with property match flow
> >>> filtering
> >>> - Removed timestamp IEs for reporting
> >>> - Mediator integrated in first picture
> >>> - Configuration parameters and IEs redefined and re-named
> >>> - Many rewording, shortened several paragraphs to improve
> >>> readability
> >>>
> >>> Kind regards
> >>> Tanja
> >>>
> >>>
> >>> -----Ursprüngliche Nachricht-----
> >>> Von: [e-mail] [mailto:[e-mail]] Im
> >>> Auftrag von [e-mail]
> >>> Gesendet: Montag, 23. Mai 2011 11:21
> >>> An: [e-mail]
> >>> Cc: [e-mail]
> >>> Betreff: [IPFIX] I-D Action:
> >>> draft-ietf-ipfix-flow-selection-tech-06.txt
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IP Flow Information Export
> Working Group of the IETF.
> >>>
> >>> 	Title           : Flow Selection Techniques
> >>> 	Author(s)       : Salvatore D'Antonio
> >>>                          Tanja Zseby
> >>>                          Christian Henke
> >>>                          Lorenzo Peluso
> >>> 	Filename        : draft-ietf-ipfix-flow-selection-tech-06.txt
> >>> 	Pages           : 25
> >>> 	Date            : 2011-05-23
> >>>
> >>>   Flow selection is the process of selecting a subset of flows from all
> >>>   flows observed at an observation point.  Flow selection reduces the
> >>>   effort of post-processing flow data and transferring flow records.
> >>>   This document describes motivations for flow selection and presents
> >>>   flow selection techniques.  It provides an information model for
> >>>   configuring flow selection techniques and discusses what information
> >>>   about a flow selection process should be exported.
> >>>
> >>>
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-
> >>> tech-06.txt
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> This Internet-Draft can be retrieved at:
> >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-t
> >>> ech-06.txt _______________________________________________
> >>> IPFIX mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ipfix
> >>> _______________________________________________
> >>> IPFIX mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ipfix
> >>
> >>
> >> --
> >> ---------------------------------------------------------------------
> >> Nevil Brownlee                    Computer Science Department | ITS
> >> Phone: [phone] x88941             The University of Auckland
> >> FAX: [phone]   Private Bag 92019, Auckland 1142, New Zealand
> >> _______________________________________________
> >> IPFIX mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ipfix
> >
> > _______________________________________________
> > IPFIX mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipfix
> 
> _______________________________________________
> IPFIX mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipfix