The first flow-related BoF (birds of a feather) took place in London in summer 2001 during the IETF meeting 51. A few months later, the IP Flow Information Export (IPFIX) working group (WG) was created, with the following goal in its charter: “This group will select a protocol by which IP flow information can be transferred in a timely fashion from an “exporter” to a collection station or stations and define an architecture which employs it.  The protocol must run over an IETF approved congestion-aware transport protocol such as TCP or SCTP”. The charter planned for three deliverables: the requirements, the architecture, and the data model. At that time, I was told the intent was to standardize NetFlow, a proprietary implementation, which was already deployed in operator networks.

And so, it started.

The WG debated for a long time on the requirements for the future IPFIX protocol selection, and hence the IPFIX architecture. There were five candidate protocols, with different capabilities, to select from, and each candidate proponents were obviously pushing their own protocol.

From there, the chairs decided that the WG should classify all requirements as “must”, “should”, “may”,  and “don’t care”. The “Requirements for IPFIX”, RFC3917 documented this outcome. An independent team, in charge of evaluating the different protocols in light of documented requirements concluded that the goals of the IPFIX WG charter would best be served by starting with NetFlow v9, documented in the mean time in the informational RFC 3954.

By that time, 3 years have passed.

The next couple of years were dedicated to IPFIX protocol specifications. According to my recollection, the WG spend one year or maybe one year and half on transport-related discussions: should we use TCP or SCTP as the congestion-aware transport protocol … while most customers only cared about UDP when the flow export collection is exclusively within their management domain … and where the distributed function of forwarding ASICs complicate congestion aware transport-requirements.
The final specifications compromise on: “SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations.  UDP [UDP] MAY also be implemented by compliant implementations.  TCP [TCP] MAY also be implemented by compliant implementations.”

The IPFIX protocol (RFC 5101) and the IPFIX information model (RFC 5102) were finally published in January 2008 as Proposed Standards. In the end, IPFIX is an improved NetFlow v9 protocol with extra features and requirements such as transport, string variable length encoding, security, or template withdrawal message.

The IPFIX WG closed in 2015, with the following results:
– the IPFIX protocol and information model, respectively RFC 7011 and RFC 7012, published as Internet Standards
– a series of RFCs regarding IPFIX mediation functions (from a subsequent charter)
– almost 30 IPFIX RFCs in total (architecture, protocol extensions, implementation guidelines, applicability, MIB modules, YANG module, etc…)
– the IPFIX community worked on PSAMP (Packet SAMPling), which selected IPFIX to export packet sampling information, and produced four RFCs.

What are the lessons learned from those 13 years of standardization?
– 7 years (or 13 years depending if you consider the Proposed Standards, or the IPFIX WG closure) of standardization is way too long, and is inadequate today, at the age of quick(er) opensource developments. This IESG (Internet Engineering Steering Group) discussed this issue during a retreat, recognized the issue, and stressed that “WGs should have solution work from day 1″, as explained by the IETF chair in his report at IETF 90. So basically, let’s not spend precious WG time on use cases and requirements, unless we have to.
– If the intent behind the charter is to standardize a specific solution (citing the OPS AD at that time, “the intent was to standardize NetFlow”), then the IESG and the charter should be clear about it. For example,”The WG should consider <draft-bla> as a starting point.”
– <Area Director hat on> Now that I’m part of the IESG, I can tell: don’t fight the IESG regarding transport protocols. If the protocol will ever run over the Internet, it must run a congestion-aware transport. Full stop. </Area Director hat on>.
<Benoit hat on>In the end, the operators will do what they want anyway, and request what they need from equipment vendors.</ Benoit hat on>

Maybe the only important question is: IPFIX is a success?
– From a specification point of view, yes. Granted, should we start from scratch today, we would change a few things, reflecting on years of experience.
– From an implementation point of view, yes.
– From a deployment point of view, not quite yet but getting there. Indeed it took so long for the IPFIX to standardize that the NetFlow v9 implementations improved along the years. The world will see more IPFIX deployments when operators will require IPFIX specific features … And there are not many SCTP IPFIX requests right now.

In conclusion, we can say that IPFIX is a success, but the world has changed a lot since 2001, lessons have been learned, and today we approach standards in the IETF differently.

Regards, Benoit (Operations and Management Area Director)