Subject: Re: [ipfix-arch] revised terminology

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 01 Apr 2002 10:35:59 -0800

Hi Jurgene, Tanja,

Juergen Quittek wrote:

> Hi KC,
>
> Here is a revised version of the terminology for the
> architecture document (as promised in Minneapolis).
> Most of the changes result from discussions with Tanja.
>
> The definitions of IPFIX device, template, control
> stream and data stream are unchanged, although I am
> not yet completely satisfied with them.
> Further discussion on all terms seems to be ahead.
>
> Cheers,
>
>     Juergen
> --
> Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
> NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
> Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>
> Terminology
>
>  * IP Traffic Flows
>    A flow is defined as a set of packets passing an observation
>    domain in the network during a certain time interval. All packets
>    belonging to a particular flow have a set of common properties.
>    Each property is defined as the result of applying a function to
>    the values of:
>
>       1. one or more of packet header fields (eg. destination IP
>          address)
>       2. one or more properties of the packet itself (eg. packet length)
>       3. one or more of fields derived from packet treatment (eg. AS
>          number)
>
>    A packet is defined to belong to a flow if it completely
>    satisfies all the defined properties of the flow.

The sentence "Each of the fields from 1., 2. and 3. are referred to
as keys.  " (from the arch spec) seems to be omitted here. This is
required for introducing the definition of flow type. What I feel is
appropriate is to pick up the entire defintion including examples
from the data model doc and stick it here also.

>
>
>    This definition covers the range from a flow containing all
>    packets observed at a network interface to a flow consisting of
>    just a single packet between two applications with a specific
>    sequence number.

The range could be broader. A flow could contain all packets
observed at one or more network interfaces.

> Please note that the flow definition does not
>    match a general application-level end-to-end stream.

I am not sure I understand this? A flow "could" match a general
application-level end-to-end stream. But it is not restricted
to this only. Is there a need to mention these lines or do you think
the flow defintion is not clear enough?

> However,
>    an application may derive properties of application-level
>    streams by processing measured flow data.
>
>  * Observation Point
>    The observation point is a location in the network where IP
>    packets can be observed. Examples are a line to which a probe
>    is attached, a shared medium, such as an Ethernet-based LAN,
>    a single port of a router, or the routing engine of a router.

Why is "a set of interfaces (physical or logical) of a router"  from the
arch. spec omitted? Aggregation of ports (like fast ether channels in
Cisco routers) is used very much in deployments.

>
>
>  * Observation Domain
>    A single IP traffic flow may contain packets observed at several
>    different observation points, for example at several ports of a
>    line card or at different probes. The observation domain of a
>    flow is the set of observation points at which the packets of
>    this flow have been or might have been observed. The minimal
>    observation domain contains just a single observation point.

From the definition above , it  would mean if R1 and R2 collect
{Src AS, dst AS} on their respective n/w interfaces  I1 and I2, then
{I1, I2} would make up an observation domain!! Let me
try to explain what I had in mind on this defintion:
The flows collected from various observation points could be subjected
to a series of sampling and classification operation in some sequence.
This result could be combining flows collected at different observation
points. An example for this is: The raw flow (5-tuple) collected at
2 observation points O1 and O2, when a furthur classification is done
to choose all the packets that match a certain destination address
would result in aggregation within the node (by node I mean a router
or a linecard which can be clearly identified as a network entity and
capable of doing such aggregation).
Observation domain consists of the set of observation points, the
metering processes, the part of maintenance of flow records (which
includes functions like aggregation) and  choosing a criteria  for
export.

>
>
>  * Metering Process
>    The metering process generates flow records. Input to the
>    process are IP packets observed in an observation domain. The
>    metering process consists of a set of functions that includes
>    packet header capturing, timestamping, sampling, classifying,
>    and maintaining flow records.
>
>    Sampling and classifying may be performed repeatedly (with
>    different parameters). The sampling function selects a subset
>    of the received set of items (packet headers with timestamps or
>    flow records) to be passed further to the classifying function.
>    The sampling function may be trivial by passing all items,
>    which is equivalent to applying no sampling at all. The
>    classifying function maps its input to flows. There are two
>    extreme classifying functions: one mapping each packet to
>    different flows and one mapping all packets to the same flow.
>
>    Maintenance of flow records may include creating new records,
>    updating existing ones, computing flow statistics, deriving further
>    flow properties, detecting flow expiration, passing flows record to
>    the exporting process, and deleting flow records.

Maintenance of flow record can be thought of as a function of
observation domain . One more functionality which is outside
the metering process is a selection criteria for export.

>
>
>    The figure below shows the sequence in which the functions are applied.
>
>                         packet header capturing
>                                   |
>                              timestamping
>                                   |
>                                   v
>                            +----->+
>                            |      |
>                            |   sampling
>                            |      |
>                            | classifying
>                            |      |
>                            +------+
>                                   |
>                        maintaining flow records
>                                   |
>                                   v
>
>               Figure 1: Functions of the metering process
>
>  * Flow Record
>    A flow record contains information about a specific flow that was
>    metered in an observation domain. A flow record contains measured
>    properties of the flow (e.g. the total number of bytes of all packets
>    of the flow) and usually characteristic properties of the flow (e.g.
>    source IP address).
>
>  * Exporting Process
>    The exporting process sends flow records to one or more collectors.
>    The flow records are generated by one or more metering processes.

There could be an option export criteria at the observation domain which
chooses which records to export.
Ganesh

>
>
>  * Collecting Process
>    The collecting process receives flow records from one or more exporting
>    processes. The collecting process might store received flow record
>    or further process them, but these actions are out of the scope of
>    this document.
>
>  * IPFIX Device:
>    A device hosting at least an observation point, a metering
>    process and a flow information export process. Typically,
>    corresponding observation point(s), metering process(es), and
>    exporter process(es) are co-located at this device, for example,
>    at a router.
>
>  * Template:
>    Templates is a set of {type, length} ordered pairs, used to
>    completely identify the structure and semantics of a particular
>    information that needs to be communicated from the IPFIX Device
>    to the collector. Each template is uniquely identified by a
>    Template ID.
>
>  * Control Stream, Data Stream:
>    The information that needs to be exported from the IPFIX device
>    can be classified into the following categories:
>
>      - Control Information :
>        This includes the flow type definition, selection criteria
>        for packets within the flow. This is also called as Control
>        Stream.
>      - Flow record :
>        This includes data records corresponding to the various
>        observed flows at each of the observation point. This is also
>        called as Data Stream.
>
> --
> 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/

--
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: Mon, 01 Apr 2002 23:40:35 +0200

Hi Ganesh,

> from the data model doc and stick it here also.

I removed it, because I did not clearly understand it (maybe my English
is not good enough). Do you means each one IS a key, or they altogether
ARE THE flow key?

If you consider 'flow key' to be an important term, than I suggest
giving it its own entry in the terminology section.

> observed at one or more network interfaces.

Right! It may even be an aggregate of packets selected at different
probes in the network.

Let's change this phrase to "... range from a flow containing all
packets observed at different probes distributed in a network to ..."

> the flow defintion is not clear enough?

Well, initially I considered it to be clear enough without this
statement. But then I learned that too many people (on the list
and in private discussions) ignored this fact even after reading
it. I guess the reason is that the term 'flow' is already around
for some time, and if you are used to think about a flow as an
application level flow it can be hard to work with a different
definition.
So, the idea behind the redundant 'reminder' is reduce the number
of people mixing up the definitions.

> Cisco routers) is used very much in deployments.

Isn't this rather an observation domain?

> capable of doing such aggregation).

You can aggregate flows beyond boundaries of a single device,
for eample by aggregating flows measured by several probes at
a concentrator (see figure from my other posting below).

       +---+     +---+     +---+
       | E-+->   | E-+->   | E-+------------->---+
       | | |     | | |     | | | +---+         +-+-----+
       +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
         |       | | |     | | | | | | +---+   +-+-----+
       +-+-+     +-+-+     | O | | M | | E-+->---+
       | | |       |       +---+ | | | | | |
       | M |     +-+-+           | O | | M |
       | | |     | | |           +---+ | | |           +-----+
       | O |     | O |                 | O |        ->-+-C-E-+->
       +---+     +---+                 +---+           +-----+

      Protocol   Remote             Concentrator        Proxy
      Converter  Observation

> includes functions like aggregation) and  choosing a criteria  for

I see, I'm sorry for misunderstanding your definition of the
observation domain. My naive idea of the word 'domain' was
rather a topological one than a functional one.

How do you think about distributed observation domains in case
of concentrators?

> the metering process is a selection criteria for export.

Yes, my fault again. I did not consider a function to be a
component of a domain.

But anyway, how can we fit it into the functional IPFIX model?

Starting with

    ObservationPoint(s) - MeteringProcess(es) - ExportingProcess

abbreviated by

    O - M - E

Now you define the observation domain (OD) as a set of
some observation points and some metering processes.

    OD = O - M

But you want it to also host some additional processes
not in the first chain: maintaining flow records (MFR)
and 'selection criteria for export' (SCE).

Shall we now extend the original chain to

   O - M - MFR - SCE - E      with      OD = O - M - MFR - SCE?

> chooses which records to export.

Agreed.

    Juergen

---

From: "kevin.zhang" <[email-masked]>
Date: Tue, 2 Apr 2002 07:09:59 -0500

Hi Juergen,

Please see my other comments inserted.

Thanks,

Kevin 

> -----Original Message-----
> From: majordomo listserver [mailto:[email-masked]]On Behalf
> Of Juergen Quittek
> Sent: Thursday, March 28, 2002 9:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ipfix-arch] revised terminology
> 
> 
> Hi KC,
> 
>    sequence number. Please note that the flow definition does not
>    match a general application-level end-to-end stream. However,
Template describes the data records exported, we don't need to constrain it to be (type, length) pairs in the requirement document.  Different descriptors should be allowed e.g. (type, length)pair, it should be specified by the architecture document. I propose to change it to -

*Template: 
Template is a set of ordered descriptors, used to completely specify the structure and semantics of a particular information that needs to be communicated from the IPFIX Device to the collector. Each template is uniquely identified by a Template ID.

>        observed flows at each of the observation point. This is also
Based on our discussions in Minneapolis, the term "Control Stream" was not agreed upon.  It appeared people like to use something else like "control information", and it is exchanged between IPFIX end points. My proposal is -

*Control Information, Data Stream:
The information that needs to be exchanged between IPFIX devices can be classified into the following categories:

- Control Information: 
Control information is exchanged between IPFIX devices to facilitate flow record exporting.  It includes the flow type definition, selection criteria for packets within the flow, and device capabilities.

- Flow record:
This includes data records corresponding to the various observed flows at each of the observation point. This is also called as Data Stream.

> Archive     http://ipfix.doit.wisc.edu/archive/��ޖ���[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, 02 Apr 2002 16:46:01 +0200

Hi Juergen,

Some comments.
Note that some of them were already made by Ganesh.

    Terminology

    * IP Traffic Flows

You changed from passing an obervation point to an observation domain.
I prefered observation point; it was more self-explaining.
You define below the observation domain. But this term is already used 
in the architecture document for another purpose.
     * Observation Domain:
       The set of observation points which is the largest aggregatable
       set of flow information at the IPFIX Device is termed as an
       observation domain. The observation domain presents itself a
       unique ID to the collector for identifying the export packets
       generated by it. One or more Observation Domains can interface
       with the same export process. Example: The observation domain
       could be a router line-card, composed of several interfaces with
       each interface being an observation point.

This is confusing. That's the reason why I would put:
- move back to the definition containing "passing an observation point"
- remove the observation domain from the requirement.
- move back to the definition of the observation which contains "or a 
set of interfaces..." See my comments below

    * Observation Point

Continuing with the same optic as above. We don't need the observation 
domain, but we need to previous definition of the "observation point" 
which containted "... Examples are a line to which a probe is attached, 
a shared medium, such as an Ethernet-based LAN, a single port of a 
router, or a set of interfaces (physical or logical) of a router."

    * Observation Domain

    * Metering Process

should be: "observed at the observation point"

      The figure below shows the sequence in which the functions are
    applied.

                           packet header capturing
                                     |
                                timestamping
                                     |
                                     v
                              +----->+
                              |      |
                              |   sampling
                              |      |
                              | classifying
                              |      |
                              +------+
                                     |
                          maintaining flow records
                                     |
                                     v

    * Flow Record

Again, observation domain -> obvservation point.
This should be the same for all over.

Regards, Benoit

    * Exporting Process

    * Collecting Process
      The collecting process receives flow records from one or more
    exporting
      processes. The collecting process might store received flow record
      or further process them, but these actions are out of the scope of
      this document.

    * IPFIX Device:

    * Template:

        - Control Information :

---

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

All,

>>       for packets within the flow. This is also called as Control
I would just say:
    - Control Information :
              This includes the flow type definition, selection criteria
              for packets within the flow and any other control messages.

Regards, Benoit

---

From: "kevin.zhang" <[email-masked]>
Date: Tue, 2 Apr 2002 16:32:01 -0500

Hi Benoit,

I would like to underscore the point that control information is bi-directional, especially now as TCP is selected as the transport protocol. Please let me know some specifics of my proposal that you don't like, I sure can revise my proposal.

Thanks,

Kevin 

> From: Benoit Claise [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2002 10:36 AM
> To: [email-masked]
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: [ipfix-arch] revised terminology
> 
> 
> All,
> 
> kevin.zhang wrote:
> 
> >
> >Based on our discussions in Minneapolis, the term "Control 
> Stream" was not agreed upon.  It appeared people like to use 
> something else like "control information", and it is exchanged 
> between IPFIX end points. My proposal is -
> >
> >The information that needs to be exchanged between IPFIX devices 
> >Control information is exchanged between IPFIX devices to 
> facilitate flow record exporting.  It includes the flow type 
> definition, selection criteria for packets within the flow, and 
> device capabilities.
> >
> >- Flow record:
> >This includes data records corresponding to the various observed 
> flows at each of the observation point. This is also called as 
> Data Stream.
> >
> ��ޖ���[h�f���h���z�ݢ+��+��njwlk/�zZ��y��Ơy��I칻�&ޙ�����j:+v���w���"��"���v�vƲ��칻�&ފ�������,j��܀��b��m����*_�ݢ+��+��n��܆+�

---

From: "K.C. Norseth" <[email-masked]>
Date: Tue, 2 Apr 2002 17:39:36 -0700

Hi Kevin,

Although I agree that bi-directional control information is very imporant,
using TCP does not signify bi-directional control information.  All it says
it we have a link establish and can detect that the collector is alive.  We
have not even specified it has to be reliable TCP,  the transport protocol
must be congestion aware.  SCTP has a congestion aware, unreliable transport
mechanism available.  The amount of control information is still up in the
air.

I do think that the chosen protocol should have bi-directional control
information.  The amount of bi-directional control is still to be decided.

K.C.

----- Original Message -----
From: "kevin.zhang" <[email-masked]>
To: "Benoit Claise" <[email-masked]>
Cc: "Juergen Quittek" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 02, 2002 2:32 PM
Subject: RE: [ipfix-arch] revised terminology

| Hi Benoit,
|
| I would like to underscore the point that control information is
bi-directional, especially now as TCP is selected as the transport protocol.
Please let me know some specifics of my proposal that you don't like, I sure
can revise my proposal.
|
| Thanks,
|
| Kevin
|
| > -----Original Message-----
| > From: Benoit Claise [mailto:[email-masked]]
| > Sent: Tuesday, April 02, 2002 10:36 AM
| > To: [email-masked]
| > Cc: Juergen Quittek; [email-masked]
| > Subject: Re: [ipfix-arch] revised terminology
| >
| >
| > All,
| >
| > kevin.zhang wrote:
| >
| > >
| > >> * Control Stream, Data Stream:
| > >>   The information that needs to be exported from the IPFIX device
| > >>   can be classified into the following categories:
| > >>
| > >>     - Control Information :
| > >>       This includes the flow type definition, selection criteria
| > >>       for packets within the flow. This is also called as Control
| > >>       Stream.
| > >>
| > I would just say:
| >     - Control Information :
| >               This includes the flow type definition, selection criteria
| >               for packets within the flow and any other control
messages.
| >
| > Regards, Benoit
| >
| > >>
| > >>     - Flow record :
| > >>       This includes data records corresponding to the various
| > >>       observed flows at each of the observation point. This is also
| > >>       called as Data Stream.
| > >>
| > >Based on our discussions in Minneapolis, the term "Control
| > Stream" was not agreed upon.  It appeared people like to use
| > something else like "control information", and it is exchanged
| > between IPFIX end points. My proposal is -
| > >
| > >*Control Information, Data Stream:
| > >The information that needs to be exchanged between IPFIX devices
| > can be classified into the following categories:
| > >
| > >- Control Information:
| > >Control information is exchanged between IPFIX devices to
| > facilitate flow record exporting.  It includes the flow type
| > definition, selection criteria for packets within the flow, and
| > device capabilities.
| > >
| > >- Flow record:
| > >This includes data records corresponding to the various observed
| > flows at each of the observation point. This is also called as
| > Data Stream.
| > >
| >
éT¨¶?ZS¢jz×SÜ±Ç¹©±¬zZzg±¨n?R{nÇ?·j)¢f¢·s?µÚ·qçjwk+²ær¸z*<Tëj¡Ü­È½è¶YS-ÅÚ
·qçýª?+

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 02 Apr 2002 22:02:43 -0800

Hi Jurgen,

> giving it its own entry in the terminology section.

Each field is termed key or flow key . Yes we can add it as a term
in the terminology.

> packets observed at different probes distributed in a network to ..."

 Just out of curiosity are there deploymens that use flows in such
a manner for probes?

> of people mixing up the definitions.

Can we re-phrase the paragragh then to:
Though a  flow could match a general application-level end-to-end
stream, it's defintion not restricted to this alone.

> Isn't this rather an observation domain?

No. Atleast on a router (I'm not sure about probes) we can group a
set of ports , say 5 fast ethernet ports to form a "port channel" . This
 interface from a L3 perspective for any traffic coming on these
5 fast ethernets is the "port channel". Similarly a tunnel interface (GRE)
can span over multiple physical interfaces.

> a concentrator (see figure from my other posting below).

What is the input to concentrator? Is it  IPFIX flow records or packets itself?
For Protocol converter, remote observation, OD = O - M - MFR - SCE fits
in well. For the concetrator case I am not sure what C-M-E do. If you can explain
furthur then we can find out. Same is the case with proxy - what is the input to it?

Thanks
Ganesh

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 02 Apr 2002 22:19:38 -0800

Benoit,
  I guess there was a confusion about the term
  "observation domain". Jurgene thought it was
  meant to convey a collection of observation
  points.
Ganesh

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 15:24:19 +0200

Hi Benoit,

I already explained to Ganesh that I misunderstood your definition
of observation domain, mainly because I did consider a domain
a topological entity, not a functional one and therefore just
interpreted it as a set of observation points without the metering
function and others inside. Now I understand your definiton.

My idea ws re-using your defintion, not overwriting it.
What I wanted to cover is the situation that a metering process
may merge packets observed at several different observation points
into one flow. Then it doea not make sense to define a flow as
a set of packets observed at a single observation point, but
potentially also as a set of observation points, which I
unfortunately called observation domain. Let's call it Set Of
Oberservation Points (SOOP) for the rest of this message. As far
as I understand, the SOOP is part of an observation domain.

Consequently, my proposal is to define a flow to be a set of
packets observed at a SOOP, not just at a single observation point.
Of course a SOOP may contain a single observation point only.

    Juergen

--On 02 April 2002 16:46 +0200 Benoit Claise <[email-masked]> wrote:

> You define below the observation domain. But this term is already used in the architecture document for another purpose.
>      * Observation Domain:
> - move back to the definition of the observation which contains "or a set of interfaces..." See my comments below
>
> Continuing with the same optic as above. We don't need the observation domain, but we need to previous definition of the "observation point" which containted "... Examples are a line to which a probe is attached, a shared medium, such as an
> Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router."
>
>
>     * Observation Domain

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 16:05:35 +0200

> Hi Jurgen,
[...]
> Each field is termed key or flow key . Yes we can add it as a term

Fine.

>  Just out of curiosity are there deploymens that use flows in such

I am not dealing with commercial deployments, but I remember that
about three years ago I was involved in a customer trial where we
used NetFlowMet to aggregate flows measured at several Cisco routers
and then exported these flows using the Meter MIB.

> stream, it's defintion not restricted to this alone.

Yes, fine.

> can span over multiple physical interfaces.

OK, then let's add it again.

> a concentrator (see figure from my other posting below).

Input to both, the proxy and the concentrator are flow records.
The proxy just forwards them. The concentrator adds another step
of metering, aggregation and flow record maintenance and then
exports potentially different flow records. So the concentrator
model would be C - M - MFR - SCE - E. In this case the observation
domain would include all Os, Ms, MFRs, and SCEs on the probes as
well as M - MFR - SCE on the concentrator.

Cheers,

    Juergen

> Ganesh
[...]

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Apr 2002 16:11:43 +0200

Ganesh,

>   meant to convey a collection of observation

Well, maybe I'm the only one.

But now I've found a nice way of understanding your definiton well:
I interpret the term 'observation domain' as the physical 'domain'
in the router hardware where observation point, metering, and
flow record maintaining functions are located :-)

Cheers,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Wed, 03 Apr 2002 18:16:16 +0200

Juergen,

Hi Benoit,

It was already the case before with the previous definitions without having
a new term

2.1. IP Traffic Flows

A flow is defined as a set of packets passing an observation point
in

the network during a certain time interval.

2.2. Observation Point

The observation point is a location in the network where IP packets

can be observed. Examples are a line to which a probe is attached, a

shared medium, such as an Ethernet-based LAN, a single port of a

router, or a set of interfaces (physical or logical) of a router
.

Regards, Benoit

Juergen

Hi Juergen,

Some comments.

Hi KC,

Cheers,

Juergen

Terminology

* IP Traffic Flows

the values of:

You define below the observation domain. But this term is already used in
the architecture document for another purpose.

* Observation Domain:

- move back to the definition of the observation which contains "or a set
of interfaces..." See my comments below

address)

number)

* Observation Point

Continuing with the same optic as above. We don't need the observation domain,
but we need to previous definition of the "observation point" which containted
"... Examples are a line to which a probe is attached, a shared medium, such
as an

Ethernet-based LAN, a single port of a router, or a set of interfaces (physical
or logical) of a router."

* Observation Domain

* Metering Process

applied.

packet header capturing

|

timestamping

|

v

+----->+

|      |

|   sampling

|      |

| classifying

|      |

+------+

|

maintaining flow records

|

v

* Flow Record

Regards, Benoit

source IP address).

* Exporting Process

* Collecting Process

exporting

this document.

* IPFIX Device:

at a router.

* Template:

Template ID.

- Control Information :

Stream.

- Flow record :

called as Data Stream.

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 03 Apr 2002 14:16:22 -0800

Hi Jurgene,

Juergen Quittek wrote:

> >        +-+-+     +-+-+     | O | | M | | E-+->---+ (0)
> >        | M |     +-+-+      (1)  | O | | M |
> >        | O |     | O |             (2) | O |        ->-+-C-E-+->
> >                                         (3)

Ok. Let's take the concentrator case only. Can there not be multiple
observation points and metering processes within (1), (2) and (3) ?
Also if each of them export IPFIX flow records, then there are 3
observation domains O-M of  (1), (2), (3). There could also be
MFR and SCE optionally. Why can't the concentrator not be viewed
as a collector with the additional M&E? Obviously I am missing
something. An example would be great to understand this better.

Thanks
Ganesh

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 04 Apr 2002 01:25:21 +0200

Hi Ganesh,

> something. An example would be great to understand this better.

I think I can agree to all your statements. The point is that
the metering process on the concentrator may aggregate individual
flows from (1), (2) and (3) to a merged flow. When this merged
flow is exported, it is necessary to report where it has been
measured. Then its observation domain includes (1), (2) and (3).
So the observation domain for this flow extends over more than
one box.

This is where I have problems. Maybe we should exclude such an
aggregation of flows measured by different boxes? Higher level
aggregation beyond device boundaries can still be done by
applications?

Cheers,

    Juergen

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 03 Apr 2002 16:19:54 -0800

> So the observation domain for this flow extends over more than

How does the export process function in (1) (2) and (3) ? Is it not same
as the export process defined by IPFIX protocol? To me it looks like
another level of aggregation beyond the IPFIX device boundary.

> aggregation beyond device boundaries can still be done by

Yes higher level aggreagtion is beyond the device boundary can
be done by applications outside the scope of IPFIX.

Thanks
Ganesh

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 04 Apr 2002 09:42:18 +0200

Ganesh,

Yes, that's the point:

What - or where - is the IPFIX boundary?
Is the maximum level of aggregation a single device?

What is the largest observation point?
Or: What is the largest set of observation points out of
    which observed packets may be aggregated into a single flow?

- single interface of a single device
- set of interfaces of a single device
- all interfaces of a device
----------------- cut? ------------------
- several devices
- entire network

Cheers,

    Juergen

[...]

---

From: [email-masked]
Date: Fri, 05 Apr 2002 09:33:42 -0500

> from the data model doc and stick it here also.

	I think he outlines a general model which is what you 
	want in a req. The other doucments can get into greater
	detail and definiyion.

	My 2 cents.

> the flow defintion is not clear enough?

	Most people think of a flow as an application level flow.
	I think it is good to point out here that we have a
	more general definition.

> includes functions like aggregation) and  choosing a criteria  for

	I'm not sure I follow 100% but if we modified Observation
	point to look at packets and IPFIX flows. Then combining O1 
	and O2 would just then make another O3? Just an idea.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 09:33:31 -0500

> Further discussion on all terms seems to be ahead.

	This talks solution not req. What if we decided to do it
	as a hardcoded record.

---

From: [email-masked]
Date: Fri, 05 Apr 2002 10:01:21 -0500

> I would like to underscore the point that control information is bi-directional, especially now as TCP is selected as the transport protocol. Please let me know some specifics of my proposal that y…

	When did we select TCP? I thought the requirement was
	congestion aware.

> > éi?¨¥¶?s?SÝ¢j'z×hSÜ"±Ç?¹©Ý±¬¡zZb?g¬±¨n?rR{.nÇ+?·¦j)m¢f£¢·hs?ÞµÚ"·¬qçnjwlk+§²æìr¸>z*_<§?ë,j>¡Ü?Èb½èm¶YÿS-âÅÚ"·¬qçnýªÜ?+Þ

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 05 Apr 2002 14:26:13 -0800

>         This talks solution not req. What if we decided to do it

What if the above line is change to :
"Templates is a set of  ordered pairs (eg. <type,length>, TLV), used to...
completely identify the structure and semantics of a particular
 information that needs to be communicated from the IPFIX Device
to the collector. Each template is uniquely identifiable by some means
(eg. by using a Template ID)."

> >  * Control Stream, Data Stream:

What was the concern for not using the above terminology -
"Stream" ?

> >        for packets within the flow. This is also called as Control

Actually the above defintion is not complete. It also includes any control messages

like keepalives that gets exchanged between exporter & collector. Basically
it is the stream that carries all the information for the end-points to understand
the IPFIX protocol and specifically for the receiver to understand and interpret
the data stream send by the sender. Does it make sense?

> >        observed flows at each of the observation point. This is also

"This includes data records corresponding to the information on various
 observed flows at each of the observation point..."

BTW I have started to update the arch. spec based on the current inputs
from the mailing list. Hope to get an update by mid next week.

Thanks
Ganesh

---

From: Robert Lowe <[email-masked]>
Date: Fri, 05 Apr 2002 17:05:23 -0600

> What was the concern for not using the above terminology -

See http://ipfix.doit.wisc.edu/archive/0849.html (both contol and stream
were found objectionable):

   The architecture document currently refers to separate control and
   data streams.  The control stream being a reliable path to exchange
   control information, monitor connectivity and other failures, and
   the data stream to send the IPFIX export payload itself.

   At this point, a number of attendees took issue with the use of the
   word "control" because it can be confusing.  In response it was
   noted that, in this context, "control [information]" refers to the
   portion of IPFIX which communicates the structure of the exported
   data.

   Consensus was that both the words "control" and "stream" are
   inappropriate.  "Data description" was suggested as an alternative.

I also noted the following...

   Also, the chairs said that explicit references to template-based
   application-level protocols need to be removed from the architecture
   document, since the IPFIX requirements do not exclude other
   candidate self-describing data encoding methods.

...but I'm not sure if that applies to what is mentioned above.

-Robert

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 05 Apr 2002 15:06:34 -0800

Hi Jurgene,
    Here are my thougts.

> Is the maximum level of aggregation a single device?

Yes. I mean an observation domain should not span multiple
network devices. Atleast I do not know of a concerete example
as to why it should be otherwise.

> What is the largest observation point?

The largest aggregatable interface defined by the network
device. This may be a single interface, a set of interfaces or a
logical interface as far as the network device is concerned.
I do not disagree with Paul's idea of heirarchical observation
points. But can't this be done outside the IPFIX device.

>     which observed packets may be aggregated into a single flow?

The set of all observation points within an observation domain.

> - all interfaces of a device

Yes cut below.

Thanks
Ganesh

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 05 Apr 2002 15:19:12 -0800

>    inappropriate.  "Data description" was suggested as an alternative.

"Data description" is not the correct alternative. It covers only a subset
of information that is being referred to. As I mentioned below,  this
covers other messages like keepalives etc. I can't think of a better word than
"control stream" as of now. Suggest people from the mailing list to provide
a better name.

>    candidate self-describing data encoding methods.

This is being done. So what do you think about the above definition
change to template?
Ganesh

---

From: Robert Lowe <[email-masked]>
Date: Fri, 05 Apr 2002 17:38:59 -0600

> "control stream" as of now. Suggest people from the mailing list to provide

Well, how about "operational messaging something-or-other" -- and I am shooting 
in the dark here.  :)  What's the something-or-other though?  Not link, and 
if not stream, can it be a flow?

> This is being done. So what do you think about the above definition

Other than a couple of agreement errors, it seems fine to me.

-Robert

---

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 08 Apr 2002 23:59:22 -0700

> if not stream, can it be a flow?

I am not satisfied.

> Other than a couple of agreement errors, it seems fine to me.

What do you mean by "agreement errors"?
Ganesh

---

From: Robert Lowe <[email-masked]>
Date: Tue, 09 Apr 2002 17:43:43 -0500

> > if not stream, can it be a flow?

I did say I was shooting in the dark!  Any other suggestions then?

Its purpose is operational, i.e. information passed between IPFIX devices 
and IPFIX collectors, so that is just another word for "control".
 
Why was "stream" objectionable?  What connotation was deemed inappropriate? 
What about "control"?  (I wasn't there.)  If it was mostly "stream" that was
objectionable, then borrow parts of the acronym ICMP that are appropriate, if
not the whole thing.  :)  Keepalives fit that model anyhow.  

> What do you mean by "agreement errors"?

Just English stuff... subject and verb tense (templates is...), or the use 
of "information".

-Robert

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 09 Apr 2002 17:25:22 -0700

> and IPFIX collectors, so that is just another word for "control".

True it  carries operational information - (protocol + meta-data).

> What about "control"?  (I wasn't there.)  If it was mostly "stream" that was

I guess people felt that "control" carries only the meta-data which is
not correct. Why not "stream" - "meta-data" could potentially be mixed with
flow records and may not be separable into a stream. But we are talking
about a conceptual view.
Still not suggesting any new term...
Ganesh

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Apr 2002 15:08:57 +0200

All,

I've been thinking about this term  "control stream". I couldn't find a 
better term.
I'm proposing that the people who were objecting at the last IETF 
meeting propose a better term; I'm remembering of Kevin Zhang (maybe 
some others).
Kevin, do you have a better wording?

Regards, Benoit

---

From: "kevin.zhang" <[email-masked]>
Date: Fri, 12 Apr 2002 14:46:26 -0400

Hi All,

I was not able to access my email over last week, so I might have missed some of the discussions.  My suggestion is to use "control information" as this is quite generic.  "control information" is typically bi-directional, but nothing prevents it going only in one-direction, e.g. from exporter to collectors.

Thanks,

Kevin

> Sent: Friday, April 12, 2002 9:09 AM
> To: Ganesh Sadasivan; [email-masked]
> Cc: Robert Lowe; [email-masked]; Juergen Quittek;
> [email-masked]; [email-masked]

---

From: Ganesh Sadasivan <[email-masked]>
Date: Fri, 12 Apr 2002 12:41:43 -0700

And for data use "flow data" ?
Ganesh

"kevin.zhang" wrote:

> > éi™¨¥¶‰šŽŠÝ¢j'z×hŠÜ"±Ç¹©Ý±¬¡zZbžg¬±¨n‡rR{.nÇ+‰·¦j)m¢f£¢·hš‰ÞµÚ"·¬qçnjwlk+§²æìr¸›z*_‹§™ë,j›¡Ü€Èb½èm¶ŸÿŠ—âÅÚ"·¬qçnýªÜ†+Þ/===

---

From: "kevin.zhang" <[email-masked]>
Date: Fri, 12 Apr 2002 16:52:03 -0400

IPFIX stands for IP Flow Information eXport. So "flow information" may be a term to consider, though flow data would be fine with me.

Thanks,

Kevin

> Of Ganesh Sadasivan
> Sent: Friday, April 12, 2002 3:42 PM
> Cc: Benoit Claise; Robert Lowe; [email-masked]; Juergen
> Quittek; [email-masked]; [email-masked]
> > I was not able to access my email over last week, so I might 
> have missed some of the discussions.  My suggestion is to use 
> "control information" as this is quite generic.  "control 
> information" is typically bi-directional, but nothing prevents it 
> going only in one-direction, e.g. from exporter to collectors.
> >
> > Thanks,
> >
> > Kevin
> >
> éi™¨¥¶‰šŽŠÝ¢j'z×hŠÜ"±Ç¹©Ý±¬¡zZbžg¬±¨n‡rR{.nÇ+‰·¦j)m¢f£¢·hš‰ÞµÚ"
> ·¬qçnjwlk+§²æìr¸›z*_‹§™ë,j›¡Ü€Èb½èm¶ŸÿŠ—âÅÚ"·¬qçnýªÜ†+Þ/===
> 
> 
> --
> Archive     http://ipfix.doit.wisc.edu/archive/ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þwýÚ"·ü"±ÏÞvæ§vÆ²þéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ

---

From: Robert Lowe <[email-masked]>
Date: Sat, 13 Apr 2002 21:07:00 -0500

> IPFIX stands for IP Flow Information eXport. So "flow information" may be a term to consider, though flow data would be fine with me.

I would encourage uniformity in approach, i.e. categorize them both the same.  
That said, I think I still favor message rather than information, since it 
more strongly implies movement or transfer between exporter and collector.

-Robert

> > Archive     http://ipfix.doit.wisc.edu/archive/éi™¨¥¶‰šŽŠÝ¢j'z×hŠÜ"±Ç¹©Ý±¬¡zZbžg¬±¨n‡rR{.nÇ+‰·¦j)m¢f£¢·hš‰ÞµÚ"·¬qçnjwlk+§²æìr¸›z*_‹§™ë,j›¡Ü€Èb½èm¶ŸÿŠ—âÅÚ"·¬qçnýªÜ†+Þ/===

---

From: [email-masked]
Date: Mon, 15 Apr 2002 10:32:20 -0400

> points. But can't this be done outside the IPFIX device.

	Sorry this response it late.

	But why do we need to limit an IPFIX device to only
	those devices that process packets directly? Why can't an
	IPFIX device be a device that processes certain kinds 
	of information? For example, IP header info, etc...
	Then our architecture can be multi-layered.

	I believe that a multi-layered approach would be a
	more scalable solution. Which, when it comes to network
	accounting, is critical.

	I must admit I haven't followed closely all the discussions
	on the architecture, so smack me down if this was already 
	covered, but I don't recall seeing it discussed.

---

From: [email-masked]
Date: Mon, 15 Apr 2002 11:24:29 -0400

From what I recall, the issue was that KC used the
term "control stream" with the meaning of "data description".
Hence the suggestion that he replace those words in his
presentation.

Seems to me "control stream" should be OK in the arch doc.
The other one mentioned by Robert Lowe is pretty good too,
that being "operational Stream".

Paul