Subject: [ipfix] IPFIX: Current issues / list digest, 22 Feb 02

From: [email-masked]
Date: Fri, 22 Feb 2002 09:33:19 -0800 (PST)

Hello everyone:

I've more or less caught up with the list dsicussions, here's my
attempt to summarise them and make a list of current issues, along with
WG cochairs comments and guidance.

I'll try to send an updated version of this around Friday each week from
now on.

Hope this helps, 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

IPFIX Co-chairs list of IPFIX issues

Nevil Brownlee, Fri 22 Feb 02

++ marks each issue
** WG co-chairs comment
 - Mailing list discussion items

   Contributors names are listed in full following the list of issues

++ Counter wrapping, long-running flows
   ** Support for both absolute counts (counters) and deltas, no clear
      consensus.
   - Benoit, 22 Feb: Close flow and export it when it nears counter wrap,
     restart as a new flow.
   - Ganesh, 21 Feb: Export flow records when counters go past a threshold,
     Keep IEs for absolute counts or delta counts, whichever is needed.
   - Peter, 21 Feb: In our experience, it's better to output deltas. Absolute 
     values are needed only if you have an unreliable data exporter.
   - KC, 21 Feb: Ability to send a flow record at any interval due to a 
     counter rollover needs to be a selection criteria.
   - Reinaldo, 19 Feb: Could someone elaborate on this?

++ Configuration: protocol
   ** Out of scope, i.e. WG should not consider this until we have
      the Arch and Data drafts well under way.
   - KC, 20 Feb: not doing that, trying to select best of existing protocols
   - Randy, 20 Feb: reminder, out of scope 
   - Reinaldo, 20 Feb, IPFIX config protocol needed, MIB OK as well
   - Fred, 20 Feb: NetFlow v9: good summary posting 
       'bi-directional config' = collector can ask exporter for reqd flows
       Fred doesn't think it would be useful, lots of IOS development,
       implications for reliability, security, etc.
       Config via an 'IPFIX Configuration MIB' would be better.
   - Juergen/Reinaldo/Paul/Benoit/Ram, 14 Feb: 'Not trying to standardise
     meter, therefore don't specify how to configure one.'
   - Mike, 13 Feb: Configuration and MIBs: "A MIB module is a concise guide
     to implementors in their design of a configuration interface (CLI, XML,
     XYZ, whatever) to manage a given techology"
   - Mark, 12 Feb: Comments on exporter-collector session management,
     session IDs.
   - Will, 11 Feb: Doesn't want 'SHOULD support in-band configuration.'

++ Configuration: Content Negotiation
   - Christian/Peter/Juergen, ~19 Feb: Collector should be able to request
     a subset of all available flow attributes, exporter should indicate
     which  attributes it can send.
   - Benoit, 19 Feb: This is pure configuration.  You tell the exporter w
     hich fields to export by defining a template.

++ Configuration: In-band Configuration
   - Christian/Peter/Juergen: This is the ability for a collector to
     ask an exporter for a particular set of flows

++ Applicability document
   *** Material currently in Arch draft.  Discuss at Minneapolis meeting.
       Charter mentions it to support Architecture draft, so its
       OK to start work on this, but don't let it distract from other
       WG drafts!  Use ipfix-app list alias for discussion.
   - Carter, 20 Feb: OK, but don't go too far off topic
   - KC, 20 Feb: Renaldo, Kevin & Tanja contributed most of this material 
     in Arch, they'd be good editors
   - Tanja, Feb 19: 'Applicability' contents proposal
   - Proposed by KC, support from Benoit

++ Middleboxes document
   *** Not in scope, material currently in Arch draft.
       Do we need a separate document?  Or put it in pplicability draft?

++ Selecting a Flow Info Export protocol
   ** Our charter says we'll select a protocol, however we'll probably
      need to look (small) improvements to an existing protocol
   - 19 Feb: KC had intended to list 'overview' descriptions of existing
     protocols in Arch draft.  Paul thinks this is premature, we should list
     'selection criteria' there instead.  KC agrees, meantime (so as not
     to loose the contributed text from B/G and Kevin) we'll shift it into
     appendices.
   - Randy, 18 Feb: realistically, i think you will have to modify any of
     the existing protocols to meet robust needs.  and yes, i think
     security should be a consideration.  [ note that snmpv3 control and
     tcp export over ipsec may meet some of the more difficult issues you
     raise ]
   - David, 18 Feb: Selection criteria are needed for this!

++ Defining a flow
   - Paul, 19 Feb: Selection process chooses packets to consider,
     flow definition rules determine which unique flows to export,
     i.e. flow definition rules may define sub-flows.  Collector may
     wish to know the selection cfriteria.
   - Reinaldo, 19 Feb: Is a subset of a flow (i.e. one formed by adding
     another filter function) not 'just another' flow?

++ Overload conditions
   - KC/Robert, 13 Feb: Should exporter or collector be allowed to hanle
     overload by changing sampling rate?  Or is it better to loose
     packets instead?

++ Security Considerations
   - Cliff, 12 Feb: text for Arch draft

B/G = Benoit & Ganesh

Benoit Calise, Cisco
Carter Bullard, QOSient
Christian Gilby, Nortel
Cliff Wang, SmartPipes
David Harrington, Enterasys
Fred True, AT&T Research
Ganesh Sadavisan, Cisco
Jean-christophe Martin, Sun
Juergen Quittek, NEC
KC Norseth, Enterasys
Kevin Zhang, Xacct
Man M Li, Nokia
Mark Fullmer, OARnet
Paul Calato, Riverstone
Peter Ludemann, Xacct
Ram Gopal, Nokia
Randy Bush (AD), AT&T
Reinaldo Penno, Nortel
Sebastian Zander, Fraunhofer Institute FOKUS
Simon Leinen, Switch
Tanja Zseby, Fraunhofer Institute FOKUS
Venkatraman G, Infosys Technologies
Will Eatherton, Cisco

++Other comments

Robert Lowe <[email-masked]>, 15 Feb:
  The lurker opinion poll (no vote)... ;-)
    In-band configuration -- not now.
    Negotiation -- limited (but that discussion is promised to follow).
  Benoit, I think this was a very perceptive comment.  It seems we are
  at times confusing the two.

Peter Phaal <[email-masked]>, 13 Feb:
  The IPFIX charter doesn't address the algorithms used by the flow
  collector, but there are system-wide issues that should be explored.
  Design choices made in the IPFIX protocol specification can have a
  fundamental effect on the capabilities of traffic management systems
  collecting IPFIX data (scalability, latency, accuracy, multi-point
  correlation, etc.)

--
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/