Subject: [ipfix-arch] Feedback on the architecture draft

From: Benoit Claise <[email-masked]>
Date: Tue, 02 Apr 2002 22:06:49 +0200

All,

Some comments on the latest architecture version f:
http://ipfix.doit.wisc.edu/arch/draft-ietf-ipfix-architecture-00f.txt
Next to what has been decided in Minneapolis.

1. Terminology
--------------
As we can see on the mailing list, the terminology is a big issue. I think there are too many places where we have a terminology section: the 
requirement, the architecture and the data model. To make sure that we are all speaking about the same terminology in the architecture and in 
the data model (based on the definitions from the requirement), in order to remove any references from the architecture to the data model and vice versa... in 2 words... to avoid confusion, I propose to:
- add this note before the termonilogy sections of the architecture 
draft and the data model draft
"Note that this terminology section contains the same definitions as in 
the terminology section of the [IPFIX-DATA] | [IPFIX-ARCHI]"
- make all definitions redundant in both drafts. It just costs a cut-and-paste but it's a lot clearer
- put the entire definition in both drafts. Ex: the IP traffic Flow should even contain the examples

2. Metering Process Functions
-----------------------------
As I proposed in Minneapolis, the entire section 5 "Metering Process Functions" from the data model should be inserted under the section 4 "IPFIX reference model" from the architecture model:
    4.1 Metering Process Functions
    4.1.1 flow classification
    4.1.2 selection criteria of packets
    4.1.2.1 function on properties that determines a flow type (Fi)
    4.1.2.2 sampling packets on a flow type (Si)
    4.1.3 selection criteria of flows for export
    4.1.4 flow expiration

3. IPFIX reference model
------------------------
The "optional metering process (flow level)" must be replaced by selection criteria of flow for export. Because this doesn't fit into the 
metering process definition: " The metering process generates flow records. Input to the process are IP packets observed ..."
Then we need a new paragraph under the section 4, referencing the Si and Fi definition that we just added in the architecture draft (see point number 2).
4.2 Selection Criteria of flows for export
   The measurement device MAY define additional rules so that only
   certain flows records are picked up for export. This MAY be done by
   either one of the two types of methods defined in 4.1.2.1 and 4.1.2.2 or
   a combination of them.
   Example:
   The flow records which meets the following selection criteria are
   only exported.
     1. All flow records whose destination IP address matches
        {20.3.1.5}.
     2. Every other (.i.e sampling rate 1 in 2) flow record whose
        destination IP address matches {160.0.1.30}.

4. Collector
------------
In the section 4.4, we can read 
"The functions of the collector MAY include:
	* Identifying and accepting export packets from different (Export Process, Observation Domain) pairs"
This last sentence should be changed to:
	"* Identifying, accepting and decoding export packets from different (Export Process, Observation Domain) pairs"

Again in 4.4, the following chapter should be removed, as it's contained in 4.5 already
"   The application(s) and the collector may be tightly coupled in one 
   system. They may also be logically or physically a separate 
   subsystem from the application(s). In which case, the communication 
   between them is beyond the scope of IPFIX. "

5. Table of Content
-------------------
There is no chapter 5.4, while there is chapter 5.5

Plus some minor corrections (mostly typo's) that I forwarded directly to Ganesh. I won't bother the mailing list with details.

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: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 15:34:47 +0200

--On 02 April 2002 22:06 +0200 Benoit Claise wrote:
[...]
> 2. Metering Process Functions

I completely agree that the metering process belongs to the
architecture document. What functions and capability the
metering process has are architectural issues, not information
model issues. The architecture documents would be incomplete
without a discussion of the metering process.

    Juergen

---

From: [email-masked]
Date: Fri, 05 Apr 2002 09:59:53 -0500

> Next to what has been decided in Minneapolis.

	Seems reasonable.

> 2. Metering Process Functions

	There was also a proposal not to do that as well.

	Again, The architecture defines what to do with flows.
	The data model will define the details of a flow in
	terms of fields available, functions available, etc..
	Only a loose definintion need be in the Arch.