Re: [IPFIX] template lifetime
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
hi Paul, all,
Comments on the running discussion inline...
Cheers,
Brian
On Sep 5, 2011, at 12:10 AM, Paul Aitken wrote:
> Benoit,
>
>>> How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ?
>> Solution 1. Out of band configuration with http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10. Note: I still envision that IPFIX caches might be configured for a short period of time on IPFIX exporters, for troubleshooting reasons.
>
> This is not mentioned anywhere in IPFIX. It's a hole.
Is the intention to plug this in 5101bis? The questionable (or at least, not yet demonstrated) interoperability of the existing spec may give us an opening to do so...
>> Solution 2. CP observes 10 (or 20, or whatever number) template refresh and conclude the right value
>
> Packet loss and network jitter make this problematic.
Indeed, but assuming a network that is working _well enough_ that the human in charge doesn't reprovision it due to unacceptable export efficiency, the long term average of template refresh times should approximate an upper bound reasonably well...
>
>> Solution 3: the CP doesn't bother and take a very high value
>
> That seems reasonable. Why not specify this as the default behaviour?
Infinity seems high enough. :) Coupled with automatic replacement on receipt of a different template with the same ID (keyed by template validity tied to the export time in the message in which it was received), it would seem to solve the synchronization problem.
>>> What are the default and acceptable range of lifetime values?
>>>
>>> Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process?
>>> eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite?
>> This is solution 4.
>
> Then it needs to be written in the protocol so EPs export it and CPs expect and action it correctly.
If we go with option 4 (unsurprisingly, I'm not a fan), then I would suggest _explicitly_ tying these timeouts to the export time in the message header, not any-old-random-clock the CP happens to have hanging around.
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix