Re: [IPFIX] timestamps, exporters, and other animals

Benoit Claise <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]>
Hi Josh,

Thanks for bringing up that point.
There are actually multiple cases

1.  Flow Records composed of MIB variables only.
Yes, we would need the time next to each counter, to be precise. At the 
minimum, a single time for all counters, assuming that all counters are 
read at the same time.
In this case, I believe that the Flow Records encoding have an advantage 
compared SNMP: the absolute timestamps.
I mean: when you receive a SNMP notification, you have the sysUpTime. 
Big deal! Hence some NMS just depends on the time the SNMP notifications 
arrives.

2. Flow Records composed of MIB variables completing the Flow IEs. 
Example: I want to poll my QoS class counters at the time of my flow
In this case, we need to pay attention to something else: we have to 
decide when to poll the counters: when the Flow started, when the Flow 
ended, multiple times along the Flow live, or ...?
Anyway, we would to attach the time next to the SNMP counters, exactly 
like in the first case.

Now, we still have the issue that some SNMP interface counters are not 
updated real-time! Obviously, this metering issue will not be solved 
with a new encoding.

Regards, Benoit.
>
> Hi all;
>
> So I wanted to start a discussion around timestamps when exporting 
> flows or OID values (qv. 
> http://www.ietf.org/proceedings/81/slides/ipfix-6.pdf).
>
> I think it'd be good thing to specify an association between a 
> timestamp, and an exported OID, flow, etc. When exporting an OID, for 
> example, I would like a way to know within some limit of certainty 
> when that OID value was actually sampled.
>
> A problem I find with SNMP is that the client can only use its own 
> timestamp of the server's reply to guess when the requested variable 
> was sampled. If there is uncertainty in the server implementation that 
> adds some delay between sampling and sending the response (without 
> even addressing variable network delay), there's no way to know when 
> the object
> was sampled with any certainty.
>
> I have also seen this problem in various sFlow implementations. There, 
> often the timestamp is added by the control plane an unknown amount of 
> time after the sample was taken.
>
> Has there been any prior work or discussion around this issue? I had a 
> few of my own thoughts about how to approach it, but I thought it 
> would be useful to start here.
>
> PS. For background - I am looking at NMS/protocol implementation for 
> OpenFlow devices, which might have very many distributed individual 
> devices with very many ports and variables per port. Therefore I'd 
> very much like to implement an efficient NMS "counter" protocol.
>
> Thanks,
>
> -- 
> Josh Bailey
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.