Subject: [IPFIX] about Collecting Process MIB objects

From: Hitoshi Irino <[email-masked]>
Date: Mon, 23 Mar 2009 15:41:14 +0900

Dear IPFIX-MIB authors and all,

I'd like to propose to add MIB objects about collecting process, if you agree 
and if you can. (I am sorry for my very late opinion, I hit on this recently.)

Collected information will be passed to another process (e.g., File Writer, 
Metering Process in Mediators and/or any applications for analyzing and/or 
displaying graphical view in Collectors) from collecting process generally, I 
think.

If the number of processed packets, bytes, and messages in Collecting Process 
(which I call them as ipfixCollectingProcessProcessedPackets/Bytes/Messages in 
this mail temporarily) can be got, I think these objects are useful to detect 
failure in Collectors (or Mediators) by comparing 
ipfixTransportSessionPackets/Bytes/Messages and these objects. Therefore I'd 
like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages.

An example situation: If a Collector's disk is full filled and File Writer 
will fail in writing, ipfixTransportSessionPackets/Bytes/Messages will be 
increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages will not 
be increased when a Collecting Process receives new IPFIX Message.

regards,
Hitoshi IRINO

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549

---

From: "Thomas Dietz" <[email-masked]>
Date: Mon, 23 Mar 2009 10:07:47 +0100

Dear Hitoshi,

since we don't have any reference to the collecting process in the MIB and
we just agreed to remove even the Metering Process ID (see previous mail on
the list) I don't see any chance to include such objects. Sorry to say so.

Best Regards,

Thomas

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hitoshi Irino
> Sent: Montag, 23. März 2009 07:41
> To: [email-masked]
> Subject: [IPFIX] about Collecting Process MIB objects
> 
> (which I call them as
> ipfixCollectingProcessProcessedPackets/Bytes/Messages in
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 23 Mar 2009 11:24:06 +0100

Hi Hitoshi,

From an architectural point of view, a File Writer is an Exporting
Process. So, ipfixTransportSessionStatsTable is the right place to count
the number of records, messages etc. written to the file.
ipfixTransportSessionDeviceMode would be set to "exporting".

The problem is that IPFIX-FILE is not considered by the MIB. You would
need to extend the Transport Session Table such that a file can be
specified as export destination.

I do not think that we want to delay IPFIX-MIB any further. However, we
can adapt IPFIX-CONF to allow monitoring the statistics you are
proposing via Netconf.

Regards,
Gerhard

>> I'd like to propose to add MIB objects about collecting process, if you agree and if you can. (I am sorry for my very late opinion, I hit on this recently.)
>> 
>> Collected information will be passed to another process (e.g., File Writer, Metering Process in Mediators and/or any applications for analyzing and/or displaying graphical view in Collectors) from collecting process generally, I think.
>> 
>> If the number of processed packets, bytes, and messages in Collecting Process (which I call them as ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail temporarily) can be got, I think these objects are useful to detect failure in Collectors (or Mediators) by comparing ipfixTransportSessionPackets/Bytes/Messages and these objects. Therefore I'd like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages.
>> 
>> An example situation: If a Collector's disk is full filled and File Writer will fail in writing, ipfixTransportSessionPackets/Bytes/Messages will be increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be increased when a Collecting Process receives new IPFIX Message.
>> 
>> regards,
>> Hitoshi IRINO

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Hitoshi Irino <[email-masked]>
Date: Tue, 24 Mar 2009 15:37:56 +0900

Hello Thomas, Gerhard,

Thank you for reply.

Thomas,
>> I don't see any chance to include such objects. Sorry to say so.
O.K. I understand.

Gerhard,
> However, we

Your comment means that it is able to get statistical IPFIX-CONF Data Model 
(e.g., rate, packets, bytes, messages, etc in Transport Session Class) by 
using "get-config" method of Netconf. Is it right?

Best regards,
Hitoshi IRINO

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 24 Mar 2009 09:45:08 +0100

Hi,

Hitoshi Irino wrote:
> Your comment means that it is able to get statistical IPFIX-CONF Data
> Model (e.g., rate, packets, bytes, messages, etc in Transport Session
> Class) by using "get-config" method of Netconf. Is it right?

Yes and no.

Yes, because IPFIX-CONF already includes all IPFIX-MIB parameters.
My proposal is to extend to model such that the Transport Session state
parameters may also describe Transport Sessions from/to an IPFIX File.

No, because Netconf <get-config> retrieves configuration data only.
You have to use <get> instead.

Regards,
Gerhard

>>>> I'd like to propose to add MIB objects about collecting process, if
>>>> you agree and if you can. (I am sorry for my very late opinion, I
>>>> hit on this recently.)
>>>>
>>>> Collected information will be passed to another process (e.g., File
>>>> Writer, Metering Process in Mediators and/or any applications for
>>>> analyzing and/or displaying graphical view in Collectors) from
>>>> collecting process generally, I think.
>>>>
>>>> If the number of processed packets, bytes, and messages in
>>>> Collecting Process (which I call them as
>>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail
>>>> temporarily) can be got, I think these objects are useful to detect
>>>> ipfixTransportSessionPackets/Bytes/Messages and these objects.
>>>> Therefore I'd like to add
>>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages.
>>>>
>>>> An example situation: If a Collector's disk is full filled and File
>>>> Writer will fail in writing,
>>>> ipfixTransportSessionPackets/Bytes/Messages will be increased but
>>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be
>>>> increased when a Collecting Process receives new IPFIX Message.
>>>>
>>>> regards,
>>>> Hitoshi IRINO
>>
>>
> 
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 30 Mar 2009 13:03:20 +0200

Hitoshi-san,

What you trying to achieve is basically a way to have the 
application-level acknowledgements, i.e. knowing when the transport 
protocol is able to transmit the data, while the collector is not able 
to write them down.

A few points:
- We discussed that capability a long time ago in the WG, and my 
recollection is that it was deemed unnecessary to overload the IPFIX 
protocol with that mechanism.
- If the Collector can detect that, it might be interesting to flag that
- However, I guess that we don't want to postpone the MIB anymore, as it 
was mentioned. So if the group wants to do something, this might be in 
the configuration data model (even there is nothing to configure in this 
case)
- Furthermore, the proposed mechanism, i.e. compare the 
packets/bytes/messages from one table to the sum of the transport 
sessionS stats for whatever Template Records/Flow Records are written 
into a File is not intuitive. If we want to do something, I'm in favor 
of a very simple flag expressing: "I can't deal with all the Flow 
Records". Then it's up to the sys admin to investigate the causes.

Regards, Benoit.

> you agree and if you can. (I am sorry for my very late opinion, I hit 
> on this recently.)
>
> If the number of processed packets, bytes, and messages in Collecting 
> Process (which I call them as