[IPFIX] recent ipfix drafts and argus

Gentle people,
I'm generally pretty quiet when it comes to IPFIX and its efforts.  But as the first
person to develop IP flow records in the 1980's, first to present the idea to the
community in 1992, the first to provide open source flow technology in 1995,
and the author of the longest lived open source flow system, argus; I feel that
I have to say something about the recent wave of IPFIX drafts.

The drafts on flow aggregation describe functionality that the Argus project started 
over 20 years ago.  The ideas of key modification, conversion of non-key attributes
to key members, aggregation operators, interval distribution and the architecture for it,
were all developed in argus a long long time ago.  draft-ietf-ipfix-a9n is basically
describing the functionality of argus's racluster(), rasplit(), and rabins() programs,
and every example given in the text of draft-ietf-ipfix-a9n can be generated using
argus's rabins(), with only a few gyrations of its command-line, today.

I personally would expect that if the IETF was going to describe something that is
"Standards Track", that there would be dozen's of implementations of this kind of
technology available, and that the WG is condensing years of experience to
arrive at a "Standards Track", but, this is not the case.  There is only one current
implementation of the complete capabilities of the features of draft-ietf-ipfix-a9n
that I am aware of, and that is in argus.

Taking just one of the technical descriptions in the draft, "interval distribution", I
am not aware of any description of this issue, or implementation of this type
of technology in the literature, outside of argus.  No Google search results for "flow
interval distribution".   In Argus we call it flow splitting.  The first line from a
Google search for "argus flow splitting" return:

Scholarly articles for argus flow splitting
… and prediction of flow statistics from sampled packet … - Duffield - Cited by 217

I'm not saying that Nick knows much about argus's support for flow splitting, but
its still pretty scary that the first hit is from a paper that is used in IPFIX documents.
One would have to assume that the IPFIX community should be aware.

My problem is that most of  draft-ietf-ipfix-a9n is prior work that is not widely
implemented, some of the features are still unique to argus.   While IETF support
of technology is a good thing, descriptions of technology without reference
is a difficult thing to interpret.  Is the IPFIX WG describing what they think is new
technology? Does the IPFIX WG think that many companies have implemented
this type of technology, and now its time to standardize it ?  Well, I'm not aware
of any implementation, open or closed, that does the complete set of what the
draft is recommending, other than argus.  So I don't think its new, nor widely
implemented.  I would say its a form of technology plagiarism.

IPFIX is considering adding non-IP flows to their definitions.  Argus is the only available
flow technology that has significant non-IP flow data models and support.  argus-1.2 had
flow generation, transport, analytics and storage of non-IP flows 20 years ago, with its
support for bi-directional ethernet, apple-talk and ARP transaction tracking and reporting.
In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and Infiniband flow
models.  Not attributes, but true flow key elements.   This work is non-trivial.

The concept that the WG would consider dropping the IP from IPFIX and think that is
all that is needed, is really so completely wrong, that its laughable, and a dis-service
to those that have done the hard work to bring situational awareness and analytics
to non-IP traffic.   The same applies to bi-directional flows, but that is another story.

I would love to think that IPFIX could focus back on flow information exchange.
Multicast, non-template based connectionless transport strategies, say over UDT
as an example, rather than getting into areas for which the WG is unprepared to
do even a reasonable job, without resorting to dubious techniques.

Just a few comments, I hope that anyone finds it useful.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

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