Subject: [ipfix] Comments on 'goals of IPFX WG'

From: [email-masked]
Date: Wed, 23 Jan 2002 13:55:43 -0800 (PST)

Hello all:

THe IPFIX working group is well under way, with our three teams busy
on finishing the 'requirements' document, and beginning the
'architecture' and 'data model' documents.

Watching the threads on the various sub-mailing lists, especially the
one on bi-directional vs uni-directional flows, it occurred to me that
we should pause a moment and review the goals of the WG.  Here are my
opinions on this - who knows, maybe they could make some 'introductory
text' for one of the documents.  Anyway, I'd appreciate any comments, 
suggestions for improvements, etc. ..

1. IPFIX is a standards effort aimed at producing a standard method
      for exporting flow information.  The key to this is to develop
      an easily-understandable, generalised, extensible data model for 
      flow information, together with a clearly-defined method for
      moving flow information from an exporter to a collector.  The
      WG's goals are to produce three RFCs: 'IPFIX Requirements,'
      'IPFIX Data Model' and'IPFIX Architecture.'

2. IPFIX is *not* trying to standardise a flow meter, i.e. a network
      entity which measures flows - we already have RFCs which do that,
      e.g. those for RTFM (2720 .. 2724).  Existing widely-used
      implementations can remain different, but might perhaps be extended
      to report flow information in the IPFIX lingua franca.

3. Instead, we recognise that network equipment vendors already have
      flow measurement systems implemented as part of their equipment.
      Our goal is to make the IPFIX flow information export system
      so good technically that all vendors will be happy to implement
      it, for the benefit of all users of the data.  A useful side-effect
      will be that IPFIX will make it easier to build and maintain 
      interoperable flow data collecting systems.

Viewed in this light, the only difference between uni- and
bi-directional flows is that bi-directional flows need attributes (e.g.
packet and byte counters) for each direction, rather than for only one
direction.  So long as these attributes are supported in the IPFIX data
model, they can be exported by bi-directional meters and recognised by
IPFIX collectors.  In other words, flow information *collectors* need to
implement *all* the IPFIX flow attributes, but *exporters* need only
implement a subset of them.

In the same way, a collector will certainly need to know the attributes
describing each flow (e.g. its source and destination IP addresses, port
numbers, etc., etc.), so the data model must include these attributes.

The balance between 'data model' - describing all the attributes used
in describing flows, reporting packet and byte counts, whether
information is to be pushed to a collector or pulled by it, and so on -
and the 'architecture' - describing how this is done, using whatever
transport protocol(s) the WG eventally decides on - is going to require
quite a lot of our design effort!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x8941      ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 23 Jan 2002 13:28:52 -0800

Hi Nevil,

>       to report flow information in the IPFIX lingua franca.

I agree with you to this point. The question I have is to what extent
does the IPFIX arch. focus on moving the method of flow selection and
relationship between the different collected types of flows w.r.t an
observation point to the collector? The collector needs this information
in order to interpret the flow data it receives.

Thanks
Ganesh