Subject: some thoughts in prep for Wed. WG meeting (was "Re: [ipfix] IPFIX WG Agenda for IETF 52")

From: Dave Plonka <[email-masked]>
Date: Mon, 10 Dec 2001 19:02:31 -0600

On Tue, Dec 04, 2001 at 04:26:47PM -0800, [email-masked] wrote:
<snip>
> AGENDA for the IPFIX Working Group Session
> 
> IETF 52, Wednesday 12 December, 1530-1730
> 
> 
> time    Item . . . . . . . .
<snip>
>  20  2  Requirements document   
>           draft-ietf-ipfix-reqs-00.txt published 6 November    *******
>           Brief overview, differences between this and
>           earlier versions, discussion.  What further 
>           changes are needed before we go to WG last call?

Here's some changes/additions that Nevil and I put together, and will
raise at the wed. meeting:

  0) add "Definitions" section (1.2?)
     a) Flow Information eXport process ("FIX process")
     b) "exporter"
     c) "collector" (alt. "importer"?)
     d) "in-band" vs. out-of-band"
     e) define Flow Information eXport "record"
        - it is the information representing a single flow

  1) Unidirectional vs. bi-directional flow definition

  2) In what ways might the exporter adapt/deal with copious amounts of
     data...
     dynamic timeouts?
     dynamic flow rules?
     dynamic sampling on/off?

  3) are ingress (and egress) interfaces one of the MUST packet properties?

<snip>
>  45  4  Getting Started on IPFIX Architecture and 
>         IPFIX Data Model Internet Drafts
<snip>
>         c) What should the sub-groups topics be, and
>            who's perpared to work in which ones?

The Architecture document should address how to deal with "interface
handles" (ifIndex vs. IPFIX configurable ifAlias-like labels).

Another question for the Architecture is when is it OK to discard "old"
flow data (rather than export it)?  Should this be configurable?

For those of you here in Salt Lake - see you Wednesday, if not before!

Dave

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
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: Juergen Quittek <[email-masked]>
Date: Tue, 11 Dec 2001 05:32:09 +0100

>         - it is the information representing a single flow

I agree, that this is a very helpful extension of the document.
When we submitted the current draft, we already had a "terminology"
or "definitions" section on our to do list for the next version.

What should probably be added is
       f) observation point

Do you suggest to rename "measuring device" by "exporter"?

>   1) Unidirectional vs. bi-directional flow definition

This will be an interesting discussion. I am already very curios
about the arguments. I am in clear favor of using a uni-directional
flow definition, although I see some arguments for a bi-directional
one.

The most obvious argument for uni-directional definition is that this
is the more basic definition. If you want to see both directions,
you just have combine two uni-directional flows.

Another important argument is the ease of implementation. If you
implement measurements on a line card of a router you save a lot
of hardware, if you just analyse incoming traffic (as you do it
already on several cards) and let outbound traffic pass without
scanning the packet headers. If you request bi-directional flow
measurement already at the exporter, then the exporter might have
to correlate traffic measurements from all its interfaces in order
to join the separate measurements in a single flow record.

Arguments for bi-directional flow definition include
  - convenience for user that want to measure bi-directional flows
  - TCP with its bi-directional nature

>   2) In what ways might the exporter adapt/deal with copious amounts of

You do not mention the most obvious option:
       stop measuring?

---

From: "Kevin Zhang" <[email-masked]>
Date: Tue, 11 Dec 2001 00:17:48 -0500

Hi All,

As we are getting started to work on the IPFIX architecture, I would like to offer few ideas to assist the discussion.  Hopefully, we can touch on these issues at our Wed. session.

1.  General Scope of IPFIX architecture.

The IPFIX architecture should describe the major functions performed by a IPFIX system.  We need to answer the following questions -
1.1  What is the IPFIX system and what are the key functions performed by such a system? 
1.2  What are the major functional elements (e.g. data exporter, data collector, etc.) within the IPFIX system? 
1.3  How to assign key IPFIX functions to various IPFIX elements? What are the interfaces and supported protocols? Reference models should be specified.

2. IPFIX Scenarios

2.1 The exporter and the collector are connected over LAN or dedicated links. This scenario maybe suitable for handling high volume data export and may use unreliable transport protocol.
2.2 The exporter and the collector are connected over WAN. This scenario may require higher level of processing at the exporter (such as aggregation), and should use a reliable transport protocol with congestion control and avoidance capability. 
2.3 Highly reliable IPFIX configuration.  This scenario should describe how to support reliability of data export as well as redundant configurations.

3. Data transport Semantics

We need to specify the required control information exchange between the layers and between the end points.  This would set up the correct context for export IP flow information to meet various application (billing, traffic profiling, etc.) requirement. 

��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Dec 2001 11:45:35 +0100

Dave, Juergen and all,

After reading the requirement I-D one more time, I also have some more comments

1. In the section 1.1 about IP flows
I'm not sure anymore about the meaning of that sentence:
   Please note that our flow definition does not match a general application-level
end-to-end
   stream. However, an application may derive properties of application-
   level streams by processing measured flow data.

2. In the section 3. about Distinguishing Flows
I would add one more comment, between brackets. Otherwise, every router will  be
compliant with IPFIX, as long as they distinguish flows somehow...

   Which combination of properties is evaluated for a particular
   measurement and how these properties are evaluated depends on the
   capabilities of the measuring device (this remark concerns a middlebox or a
traffic measurement probe compared to a
   router)
   and on its configuration. The configured choice of evaluated properties strongly
depends on the
   environment and purpose of the measurement and on the information
   required by the data collector.

3. In the section 4.1. about Reliability

   The measurement process MUST either be reliable or missing
   reliability MUST be known and indicated. The measurement process is
   reliable, if each packet passing the observation point is measured
   according to the configuration of the measuring device. If, e.g. due
   to some overload, not all passing packets can be included into the
   measurement process, then it SHOULD be stored at the measuring
   device, that flows might be measured inaccurately.

To be consistent with the beginning of the paragraph, the last SHOULD must be a MUST

4. A typo detail on section 8
        Special caution is required if security applications rely on IPFIX data With
forgery of exported

should be
        Special caution is required if security applications rely on  IPFIX data.
With forgery of exported

5. We should define which protocols we are monitoring with IPFIX.
IP, obviously.
But what about ICMP, IGMP, etc ... (as pointed by [email-masked]) This is a
good idea!

Regards, Benoit

---

From: Robert Lowe <[email-masked]>
Date: Tue, 11 Dec 2001 10:05:14 -0600

<snip>

> To be consistent with the beginning of the paragraph, the last SHOULD must be a MUST

The last clause does not make sense ("that flows might be measure inaccurately").
Either someone means "since flows...", or "in order that... measured accurately", 
regardless of SHOULD vs. MUST.  Also, there is a syntactical problem here, since 
"it" is never defined -- if not all packets, then "it"?

This would seem to me to be tied to same issues Dave/Neil brought up
below.  Saying that something MUST be stored at the measuring device
would seem to imply that the measuring device have infinite capacity,
since one can imagine an infinite overload situation.  ;-)  Why should
the approach for uni-directional or bi-directional flows be any
different?

I promise to read the next revision, but I would strongly suggest
uniform terminology, e.g. don't interchange "measurement device" and
"exporter" unless there is a reason to do so.

-Robert

---

From: Dave Plonka <[email-masked]>
Date: Tue, 11 Dec 2001 10:30:30 -0600

<snip>
> What should probably be added is

Yes, I'm not sure I understand the use of that term yet.
 
> Do you suggest to rename "measuring device" by "exporter"?

In short, yes.  We can discuss this in the meeting and summarize the
proposal to the list following the meeting tomorrow (Dec 11).

> This will be an interesting discussion.

Agreed - I'll leave it at that until the meeting minutes.

<snip>
> You do not mention the most obvious option:

Yes, that is a fair addition to stop exporting, or stop exporting flows
of a particular type.

I'm not trying to list all options, I just want to introduce the idea
so that we can explore how the Requirements I-D might allow the
exporter to change its behavior "on the fly" due to resource and
bandwidth limitations, perhaps as configured.

Interestingly, "draft-duffield-framework-papame-00" mentions some of
these issues.  For those that haven't looked at it, it has a lot of
issues in common with our effort.

Dave