Subject: RE: [ipfix-req] IPFix Summary

From: "Tal Givoly" <[email-masked]>
Date: Fri, 15 Nov 2002 17:08:18 -0800

IPFix SummaryReinaldo,

Thanks for putting this all together and sorry for the late response.  I'll
try to address all the open issues you summarized below from my perspective
(including agreement's to advance consensus where appropriate) - comments
interspersed throughout this note  :
  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Reinaldo Penno
  Sent: Sunday, October 27, 2002 2:31 PM
  To: [email-masked]
  Cc: [email-masked]
  Subject: [ipfix-eval] IPFix Summary

  I burned a good chunk of my weekend trying to summarize our discussions.
If you think I didn't capture what was said adequately, please speak up.
This email does not substitute Juergen's on open issues, but is actually
trying to close some of those open issues. (Should I copy the main ipfix
list?)

  I revised most of the emails starting from Jeff Meyer's - "Discussion of
Candidate Protocols" on - 9/30.

  a)Regarding metering requirements and protocol candidates.

  There is consensus that the metering requirements should be N/A when
choosing the IPfix Export Protocol.

  A good summary was provided by Peter.

  * The protocol should cover only the issues of delivering data from the
exporter to the collector. It must be expressive

  enough to contain all the data defined in the data model.

  * The data model should cover the identification of the metrics and
attributes, their meanings, and how they are grouped

  together.

  * The architecture should cover issues such as where data are observed,
what data are required and what are optional, when

  reliability is needed, how the data can be manipulated (e.g., calculating
bandwidth), etc., etc.
  [Tal Givoly] Agreed.

  b) Regarding reliability

     - Congestion awareness.

  It is covered on the requirements draft
  [Tal Givoly] Agreed.

     - Message ordering (critical when the data spans several packets, e.g.
variable length fields)

  It seems there is consensus that message ordering is important.
  [Tal Givoly] Agreed.

     - Transport reliability -

  There is some confusion around this problem since transport reliability is
*not* explicit mentioned in the reqs draft, but

  since congestion awareness is, some people take it for granted.
  [Tal Givoly] I believe we should make explicit whether a transport such as
TCP or SCTP is mandatory or not - that issue has yet to be resolved.
Obviously, one of the candidate protocols (namely NetFlow) is still based on
UDP - is that a permitted mode of operation of the protocol or is that not?
We need to resolve this issue.

     - require application-level ACKs in the protocol (SHOULD be after
       data are persisted)

  There is consensus that application layer ACKs is important
  [Tal Givoly] Agreed.

     - require enable de-duplication of received records through a unique
key

  There is consensus that de-duplication is important.
  [Tal Givoly] Agreed.

     - Exporter should keep track of number of flow records + some important
totals
       and and periodically communicate this information to the
       collector.

  There is consensus that this or some other solution to capture the
  amount of lost *flow records for each key/field* (not packets) is
important
  [Tal Givoly]

  I agree in principal (there will always be situations where data can be
lost because of extended network outages, buffer overflows, insufficient
CPU, etc.),  but it is difficult to assume that all devices will be able to
report specific information without considerable sacrifice. So, rather than
having something that cannot be properly implemented, I would rather see
this issue refined as part of the data model.

  c) Regarding High-Availability

  we should have the ability to send to multiple collectors and for the
  exporter to be able to switch from one collector to another.
  [Tal Givoly] Agreed.

  d) Regarding Timestamps

  New text for section 5.4 (Disclaimer before somebody goes for my neck:
this affects the
  architecture/requirements, not the protocol evaluation.)

     The metering process MUST be able to generate wire-line timestamps
     (rather then flow cache timestamps) for the first and the last
     observed packet of a flow. The timestamp resolution MUST be at least
     the one of the sysUpTime [RFC1213], which is one centisecond.

  [Tal Givoly] Agreed.

  e) Regarding the Views on the Problem

  Some people advocate that exporting IP flows has nothing unique to it,
it's well known problem
  only with a different data model. I hope I captured this right. Anyway,
here it goes a quotation.

  "However, the statement that IP flow is somehow unique
  in its data requirements and as such a more generalized
  "data mover" is somehow problematic, is just plain wrong."
  [Tal Givoly] Agreed.

  f) Regarding the Field Experience of IPDR

  Some people wanted more information on this, so I'm pasting an email
  from Aron Heintz [[email-masked]]. Any more in-depth information please
direct your
  questions to Jeff Meyer [[email-masked]] or Aron Heitz.
  [Tal Givoly] Feedback regarding this item shall be provided on a separate
thread.

  Thanks again for pulling all this together.

  Tal