Subject: [ipfix-req] Some extra changes for the req. document

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Feb 2002 14:24:25 +0100 (CET)

All,

Some more proposed changes.

1.
I would like to complete the following sections, with the non-indented text

3. Distinguishing Flows

   Packets are mapped to flows by evaluating their properties. Packets
   with common properties are considered to belong to the same flow. A
   packet showing at least one difference in the set of properties is
   considered to belong to a different flow.

   The following subsections list a set of properties which a measuring
   device MUST, SHOULD, or MAY be able to evaluate for mapping packets
   to flows. Please note that requiring the ability to evaluate a
   certain property does not imply that this property must be evaluated
   for each packet.

In other words, compliant with IPFIX means that the box in general must be
able, via its configuration, to somehow support to distinguish flows via all the MUST fields, even if in certain circumstance/for certain applications, only a
subset of the MUST fields is needed and only a subset of the MUST fields
is effectively used to distinguish flows.

   Which combination of properties is evaluated for a particular
   measurement and how these properties are evaluated depends on the configurati   on of the measuring device. 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

5.1. Information Model

   The information model for a flow measurement report is the list of
   attributes of a flow to be contained in the report (including the
   semantics of the attributes).

   This section lists attributes a measuring device MUST or MAY be able
   to report. This does not imply that a report MUST contain all
   REQUIRED attributes, but that it MUST be possible to configure the
   device in a way that all of the REQUIRED attributes are contained in
   a report for each measured flow.

In other words, compliant with IPFIX means that the box in general must be
able, via its configuration, to somehow support to report all the MUST fields, even if in certain circumstance/for certain applications, only a subset of the
MUST fields is needed and only a subset of the MUST fields is effectively reported.

2.
Do we have to specify so many MUST as Information Model fields?
I would vote to have only  counters and timestamps as MUST and all the rest as MAY. So the MUST are 7,8,14,15: packet counter, observed byte counter, timestamps of the first packet observed, timestamp of the last packet observed.

3.
The information model attributes 5 and 6 should specify TCP or UDP, not be confused by the interfaces.
And we should add the following attributes: input and output interfaces

Regards, Benoit

--
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: Tanja Zseby <[email-masked]>
Date: Tue, 19 Feb 2002 14:42:17 +0100

Hi Benoit,

I agree with must of your changes, except issue 2. (see below)

>I would vote to have only  counters and timestamps as MUST and all the rest as MAY. So the MUST are 7,8,14,15: packet counter, observed byte counter, timestamps of the first packet observed, timesta…
All the MUSTs in the information model are derived from applications 
that need them. If we would like to change anything here, we have to go 
again through the table with the applications and check wether really 
all applications can live without the attribute or we need to reduce the 
scope of the application in order to change the requirements for IPFIX.

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 19 Feb 2002 16:00:38 +0100

Hi Tanja, Benoit,

> scope of the application in order to change the requirements for IPFIX.

Having only 7,8,14,15 as a MUST is not sufficient. 18 certainly is a MUST.
And you yould need to export at least some ID to where you can map 7,8,14,15
I still think that most of the musts are required, but at least some are questionable 
e.g. 11,12,16,17,19

More issues in section 5.1:

- Rename "transport type" to "transport protocol type" in (4.) (align to section 3.2)
- Rename "observed byte counter" to "byte counter" and specify what exactly is
  counted (8.)
- Rename "measuring device" to "exporter" in 19. It's not clear to me whether this is
  a MUST. If it's not a MUST the underlying assumptions must be added to the draft.

-- Sebastian