Re: [IPFIX] Start of new WGLC for Flow Selection Techniques draft

Hi, Nevil, all,

This is my WGLC review for the flow selection techniques draft (revision 09). I have not performed a full editorial review; the comments here go primarily to content. The document will need an editorial pass. Capitalization, above all, seems arbitrary, especially with respect to defined terminology.

The diffs from -07 look good, in general. There seems to be no difference at all between -08 and -09 aside from the revision number. I have the following specific concerns, however:

First, I'm still of two minds on the intended status of the document (see my message to the list of 1 March 2011 for my first rant on this topic: http://www.ietf.org/mail-archive/web/ipfix/current/msg05775.html). It still reads much like what it is: a port of PSAMP to the flow domain. It doesn't address in sufficient depth other aspects of what I would take to be the main point of flow selection at a mediator. 

The following may be more indicative of my experience than anything else. I pretty much only work with non-sampled flows built from non-sampled packets (discounting the reliability of capture, metering, and export), which I know makes me kind of weird. So the only flow selection criterion presented within the document which interests me at all is property match filtering, and what's there is rather anemic. It doesn't provide an easy way to express

1. negated intervals, 
2. disjoint intervals, 
3. interval sets,
4. partial matches on flags IEs (i.e., "all ECN CE packets" which requires masking the ToS byte),
5. properties made up as a combination of IEs (e.g., "all packets with a source on the two main ETH Zürich netblocks, 129.132.0.0/16 + 82.130.0.0/16", which requires source address as well as source prefix length),
6. general boolean expressions (e.g. "all TCP flows with less than three packets plus all one packet UDP flows") ...

These are just examples off the top of my head relating to things I've had to do in the past few months. I think there are more in my message of last March.

Again, I think that trying to do full property-match filtering in a non-restrictive, implementation-independent, and acceptably flexible way is really, really hard. So I'm okay if this document doesn't attempt to do it. But I would be a bit concerned with a statement that came out of the IPFIX WG that endorsed this rather limited approach as The Way to select flows based solely on their properties. Remedies, as before, include reducing the document to Informational status or explicitly restricting its scope to clarify that the purpose is solely data reduction for operational purposes and not data analysis. 

This has gone on long enough, though, so if my case is a corner case and the rest of the WG is okay with it, I won't object; I just won't implement it or claim compliance. 

Second, The IPR issue is still a bit troubling. Without reference to the merits of the claim itself, I concur with your suggestion to follow the PSAMP route of making all flow selection methods explicitly optional. This would require a new revision before sending it up to the IESG.

Third, I'm a little confused as to why you're hardcoding a set of hash functions (BOB, IPSX, CRC) into an Information Element definition, though I notice the same thing was done in PSAMP. What if I want to use another hash function? It is not clear to me that this set of flow selector algorithms is sufficiently general that it will never be added to in the future. If this is the case, the values of flowSelectorAlgorithm should be backed by an IANA subregistry. If it is exhaustive not counting the hash functions, then the flowSelectorAlgorithm IE should have a Hash Function code point, and a flowSelectorHashFunction IE backed by an IANA subregistry should be used for hash functions.

Fourth, samplingFlowInterval and samplingFlowSpace are defined as unsigned32; why? Especially for space, I could see wanting to wait more than 2^32 flows for certain applications. Similarly for flowSamplingTimeInterval and flowSamplingTimeSpace, unsigned32 microseconds will only give you the ability to express intervals up to 4,300 seconds, or about an hour and twelve minutes. This seems arbitrarily restrictive. I would suggest that if these remain expressed as they are, they should be defined as unsigned64; RLE can always be used if the common cases only need 32 (or even 16) bits.

Fifth, Please review the references for whether they are normative or informative. I'm pretty sure that 5101, 5470, and 6183 are normative. Also, as the document is still in the WG process, it makes sense to replace the 5101 and 5102 references with their -bis counterparts.

Nits: 

Check the capitalization of information element names (e.g., section 7.1 should be flowSelectorAlgorithm; capitalization is inconsistent in section 8.1).

I'm not sure that a table is the best way to present the information in section 8.1. You can refer back to the subsections of section 7 instead.

Best regards,

Brian

On Feb 1, 2012, at 11:03 AM, Nevil Brownlee wrote:

> 
> Hi again all:
> 
> I should have said this in my last post - In Taipei we said "this
> needs a new WGLC,"  this is the notice that it starts today, and
> will finish on Wednesday, 15 February.
> 
> I need at least two emails supporting it, so do please have a look,
> even if you only say "looks OK now!"
> 
> Cheers, Nevil
> 
> -- 
> ---------------------------------------------------------------------
> 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]
> https://www.ietf.org/mailman/listinfo/ipfix

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