Re: [IPFIX] recent ipfix drafts and argus

Hi Carter,

After trying to abstract the style of your email, which I don't 
appreciate, I'm not too sure how to read your email.
Is this an IP claim? Or just "I've been doing this for years, so I know 
better"?

In all cases, that's a nice advertisement for your company... Maybe it 
was the point...

On my side, I certainly don't get my ideas from your products!
The last time I looked up your web site was at the time of RFC3955.
In total in my live, I don't think I spend more than 1/2 h on your web site.

And I don't feel like replying to the details of this email, or even 
playing the little game of comparing features of your company/my company.

Regards, Benoit.
> 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*
>       <http://scholar.google.com/scholar?q=argus+flow+splitting&hl=en&as_sdt=0&as_vis=1&oi=scholart&sa=X&ei=-8NLT_6lKcnb0QHVs6z7DQ&ved=0CBoQgQMwAA>
>
> ... and prediction of *flow *statistics from sampled packet ... 
> <http://www.google.com/url?url=http://scholar.google.com/scholar_url%3Fhl%3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%26sa%3DX%26scisig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&rct=j&sa=X&ei=-8NLT_6lKcnb0QHVs6z7DQ&ved=0CBsQgAMoADAA&q=argus+flow+splitting&usg=AFQjCNFuMuC_b45uErbgoPHPab61egoZ3g> - 
> 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

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