Subject: Re: [ipfix-info] simple editorial changes for the information model draft

From: Juergen Quittek <[email-masked]>
Date: Mon, 13 Jun 2005 17:20:21 +0200

Benoit,

--On 6/13/2005 4:06 PM +0200 Benoit Claise wrote:

> Juergen,
>
>>
>>> - Section 5.2.6  observedFlowTotalCount
>>>
>>>    Description:
>>>       The total number of Flows observed in the Observation Domain since
>>>       the Metering Process (re-)initialization for this Observation
>>>       Point.
>>>    ElementId: 3
>>>
>>> We should be in line with the RFC 3954 that explains something
>>> different: Number of Flows that were aggregated;
>>
>>
>> Fine to be in line.  But what means RFC 3954 with "Flows that were
>> aggregated"?
>> The common definition of flow aggregation is merging individual flow
>> records
>> of different flows into a single one.  This is in line with the last
>> paragraph
>> on page 4 of RFC 3954.  But this is not what I understood so far as the
>> semantics of Information Element #3 "observedFlowTotalCount".
>
> It's because the ElementId 3 name and description changed along the different versions.
>
> flowCount (version 3) -> totalFlowCount (version 6) -> observedFlowTotalCount (version 7)

This is not the point.  My comment applies to flowCount as well as
to totalFlowCount and to observedFlowTotalCount.

> I guess you want:
> - Element Id 3 to be in line with RFC3954
> - A new I.E. for observedFlowTotalCount, if you have a need for it

Sorry, I cannot follow:

What is wrong with the current description?
Is it the term 'total'? Is IE #3 a delta counter?

I do not like the description from RFC3954, because I think the
term "aggregated" is wrong.

>>> - Section 5.10.3 flowEndReason
>>>
>>>    Description:
>>>       The reason for flow termination.  The range of values includes
>>>    Abstract Data Type: octet
>>>    Data Type Semantics: identifier
>>>    ElementId: 136
>>>    Status: current
>>> The description is incomplete.  The person who requested it should
>>> complete the description
>>
>>
>> This was my fault.  I used the wrong XML tag and the list of reasons
>> disappeared.  It is
>>
>>   0x01: idle timeout
>>   0x02: active timeout
>>   0x03: end of Flow detected (e.g. TCP FIN)
>>   0x04: forced end
>>   0x05: cache full
>
> What does the force end mean?

And end of this flow enforced by any component of the architecture and
that is not covered by any of the other reasons.  You can end a flow by
shutting down the IP interface, by terminating the metering or exporting
process, ...

> Regards, Benoit.

Thanks,

    Juergen

--
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: Benoit Claise <[email-masked]>
Date: Mon, 13 Jun 2005 22:48:51 +0200

Hi Juergen,

> to totalFlowCount and to observedFlowTotalCount.

flowCount and totalFlowCount??

> Is it the term 'total'? Is IE #3 a delta counter?

You need some NetFlow internal information in order to understand the 
I.E. # 3 as defined in RFC3954
The NetFlow metering process works with a main cache from which flow 
records are expired. From there, you can aggregate flow records further 
into smaller caches.
Typically example: the main cache contains the src and dst IP addresses, 
while the aggregation cache contains the src and dst prefixes.
For each flow records in the aggregation cache, the Element Id 3 
(defined as "Number of Flows that were aggregated" in RFC3954) contains 
the number of flow records that we aggregated from the main cache into 
this flow in the aggregation cache.

Note that this was not described in RFC3954, as this RFC deals with the 
export protocol and not the metering process.

> term "aggregated" is wrong.

However, this is the right term according to my explanation above. :)

So basically, I'm suggesting:
- Element Id 3 should be in line with RFC3954. If you consider this I.E. too Cisco specific, then mark it as reserved 
but it would be a source of confusion to change his description.
- So if you need an I.E. that matches the following definition, i.e. the IPFIX-INFO version 7 description of 
observedFlowTotalCount, then I advice to allocate a new I.E. #
   Description:
      The total number of Flows observed in the Observation Domain since
      the Metering Process (re-)initialization for this Observation
      Point.

Does it make sense now?

> shutting down the IP interface, by terminating the metering or exporting

Fair enough, then it should be described.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 14 Jun 2005 01:47:16 +0200

> flowCount and totalFlowCount??

Yes, my problem is the term 'aggregated'.
This does not harmonize with any of the three names.

> You need some NetFlow internal information in order to understand the I.E. # 3
> as defined in RFC3954 The NetFlow metering process works with a main cache from
> which flow records are expired. From there, you can aggregate flow records further
> into smaller caches.  Typically example: the main cache contains the src and dst
> IP addresses, while the aggregation cache contains the src and dst prefixes.
> For each flow records in the aggregation cache, the Element Id 3 (defined as
> "Number of Flows that were aggregated" in RFC3954) contains the number of flow
> records that we aggregated from the main cache into this flow in the aggregation
> cache.
>
> Note that this was not described in RFC3954, as this RFC deals with the export
> protocol and not the metering process.
>>

I see. It is correct. But only for the Cisco implementation and not necessarily for,
say, NetFlow with IPFIX support.  And it is not necessarily correctly understood by
readers without knowledge of undocumented internals of the Cisco NetFlow implementation.

We use the term 'aggregated' in the terminology sections of protocol and architecture.
But the way we use it is fully in line with the idea of fine grain micro flows that
CAN BE aggregated into coarser grained macro flows (but not necessarily ARE aggregated).
The term "aggregated flows" can easily interpreted as including all flows that result
from an  aggregation of micro flows, but excluding non-aggregated micro flows.  This
(argueable) understanding would be wrong. (Also RFC 3954 uses the term 'aggregated' in
the definition of the collector with respect to aggregating existing IPFIX flow records.

Therefore, we should replace 'aggregated' flows by 'metered' flows, 'observed' flows
or something else that is understood with less ambiguity.

Still my question is:  What is wrong with the current description?

> - Element Id 3 should be in line with RFC3954. If you consider this I.E. too Cisco
> specific, then mark it as reserved but it would be a source of confusion to change
> his description.

No. It is not too Cisco-specific.  Just it's description is.
Why do you think the current description does not match the Cisco implementation of #3?

> - So if you need an I.E. that matches the following definition, i.e. the IPFIX-INFO
> version 7 description of observedFlowTotalCount, then I advice to allocate a new I.E. #
>    Description:

I still do not understand the problem with the current definition.
Is it a delta counter? Then we should rename it to observedFlowsDeltaCount.

> Fair enough, then it should be described.

Fully agreed.  I will extend the description accordingly.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Jun 2005 18:52:38 +0200

Dear all,

So far I misunderstood this issue raised by Benoit.
On Tuesday discussed it on the phone where he explained it to me
in detail and now I share his view.

Information element #3 does indicate the number of (fine grained)
flow records of the first level flow cache that are aggregated
into a single flow record in the second level flow cache of the
Cisco NetFlow implementation.  This value is reported per flow.

Since the design of first and second level flow caches may vary
from implementation to implementation, it does not make sense to
standardize this information element.

However, it does make sense standardizing an Information Element
'observedFlowTotalCount' as described in the current information
model. We just need to assign it a different number as suggested
by Benoit.

Thanks,

    Juergen