Subject: Re: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt

From: "Shmulik Nehama" <[email-masked]>
Date: Thu, 7 Jan 2010 01:10:01 -0600

The proposal to add the new information element "reliabilityReasonCode"
makes sense...providing more clarity as to why a device is not reporting
to the collector process. You propose two possible codes 0x00 and 0x01
for General and Reset. Will it not make sense to also have a code
specific for when a device was under a hard reboot and has no
information as to the start and end times of the reset? I am of the
opinion that there may be collector apps interested in knowing if the
device has rebooted...of course there are challenges involved in
detecting a hard reboot and not all devices may be able to report
information on such state change.

Comments from anyone?

Thanks

Shmulik Nehama

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of sujay gupta
Sent: Tuesday, December 08, 2009 12:22 PM
To: [email-masked]
Cc: Juergen Quittek
Subject: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt

HI,

Request you to provide your comments and feedback on the following draft
which has been submitted;

Title:
                Reliability Template Extension for IPFIX
           draft-gupta-ipfix-reliability-template-ext-00.txt

Brief:
"IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be
reliable the individual components like the Metering process or the
Exporting process should not fail to meter & export the flow information
to the collector, else indicate its incapability explicitly.

Currently, IPFIX transmits failure by sending count of packets,flows it
failed to process along with the duration of the failure.

This document outlines some of the limitations an IPFIX device may have
and suggests solutions."

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gupta-ipfix-reliability-templa
te-ext-00.txt

Thanking you,
-Sujay
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 07 Jan 2010 10:04:47 +0100

Hi,

> information on such state change.

We already have systemInitTimeMilliseconds.

By exporting this IE (e.g., in an Option), the Collector will know when 
a reboot occurred.  Furthermore, all relative counters are reset at this 
time.

You can calculate the gap between the last reliability report (including 
octet and packet counters) and the new systemInitTimeMilliseconds value:

(new_systemInitTimeMilliseconds)/1000  - Export_Time_of_last_rel_report

This is the period of time for which you do not know how many packets 
were discarded.

If you want to have this information with higher precision, you can add 
a millisecond time stamp to the reliability report (e.g., 
observationTimeMilliseconds).

So, I'm not sure if we need reliabilityReasonCode.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
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: sujay gupta <[email-masked]>
Date: Fri, 8 Jan 2010 23:39:27 +0530

Hi Gerhard,

Usage of the existing IE or a new IE , either would serve the purpose.
Just the use of an explicit information
sound's better.

BR,
-Sujay

On Thu, Jan 7, 2010 at 2:34 PM, Gerhard Muenz <[email-masked]> wrote:
> By exporting this IE (e.g., in an Option), the Collector will know when a
> reboot occurred.  Furthermore, all relative counters are reset at this time.
>
> This is the period of time for which you do not know how many packets were
> discarded.
>
> If you want to have this information with higher precision, you can add a
> millisecond time stamp to the reliability report (e.g.,