Subject: Re: [IPFIX] template lifetime

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Sep 2011 17:18:40 +0200

Brian,
> Hi, Paul,
>
> My personal opinion is that, if we're not going to deprecate UDP with prejudice (which I realize to my sorrow we cannot do), we should jettison all this template lifetime nonsense. We spent an inordinate amount of time on 5101/5102 the first time around trying to come up with sensible guidance, then gave up and basically said "template lifetimes are configured out of band according to operational environment and application constraints", which is essentially RFCese for "here, you make this work." Which is actually sensible: there is no default that covers edge-network, core-network, and IPFIX-as-SNMP-replacement-on-the-moon use cases.
>
> Half a decade later, there has never been a successful interop test to my knowledge demonstrating the template management (expiry, withdrawal, reissue) features in IPFIX.
Sure. It's only when you exhausted the number of Template ID than you 
need "reiusse", when then need "withdrawal". Note: I know of such use 
case/implementation.
"Expiry" is a different problem.

Regards, Benoit.
>
> Most export applications use one, two, twenty, thirty templates, and that's all they'll ever use, because those templates reflect the core data model in use by the application, and the export app wants to waste as little effort in export transcoding as possible. Sure, collectors in the wild have to handle more templates than that, but it doesn't take long as a collector operator (or even implementor) to realize that practically speaking, nobody is ever going to reuse an ID on you without dropping a session, and just setting your template expiry time to something practically infinite . You interpret templates as they come in, you replace old with new, and everything works unless you find yourself in an insanely rare corner case -- and if you do, you write something to the log and wake up the human.
>
> Trying to export template lifetime information from EP to CP adds complexity while pretending that the system as specified works better than an infinite-lifetime-at-collector with silent replacement, which IMO is not the case.
>
> I'd propose we use the RFC5655 File Reader template rules (accept anything that would be legal on any transport in any combination), but I don't know the right way to do this in 5101bis: perhaps filing technical errata on all the "MUST drop the session" language on the grounds that 1. a receiver cannot always reliably signal session failure to a transmitter and 2. it violates the "be liberal in what you accept" principle of protocol design.
>
> Cheers,
>
> Brian
>
> On Aug 18, 2011, at 11:34 AM, Paul Aitken wrote:
>
>> Dear IPFIX experts,
>>
>>
>> RFC5102, section 10.3.7 ("Collecting Process") says:
>>
>>    The Collecting Process MUST associate a lifetime with each Template
>>    (or another definition of an identifier considered unique within the
>>    Transport Session) received via UDP.  Templates (and similar
>>    definitions) not refreshed by the Exporting Process within the
>>    lifetime are expired at the Collecting Process.
>>
>>    ...
>>
>>    The Template lifetime at the Collecting Process MUST be at least 3
>>    times higher than the Template refresh timeout configured on the
>>    Exporting Process.
>>
>>
>>
>> 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." ?
>>
>> 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?
>>
>> Thanks,
>> P.
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Sep 2011 17:19:13 +0200

Paul,
> Brian, Gerhard,
>
> Thanks for your replies. I know it's an old problem, but someone asked 
> what the default refresh interval should be.
>
> So it seems we should either define a mechanism for Exporters to 
> inform Collectors what their default refresh interval is (eg, define a 
> new standard options template), or re-work (or even remove?) the 
> template timeout sections.
>
> Currently this is a gap which allows an Exporting Process and a 
> Collecting Process to both claim to be IPFIX compliant, while being 
> quite un-interoperable.
Can you please clarify the un-interoperable aspect. I don't get it.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Sep 2011 17:15:49 +0200

On 18/08/2011 11:34, Paul Aitken wrote:
> 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.
Solution 2. CP observes 10 (or 20, or whatever number) template refresh 
and conclude the right value
Solution 3: the CP doesn't bother and take a very high value
> 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.

Regards, Benoit.

---

From: Paul Aitken <[email-masked]>
Date: Sun, 04 Sep 2011 23:10:16 +0100

Benoit,

> Paul,
>> Brian, Gerhard,
>>
>> Thanks for your replies. I know it's an old problem, but someone 
>> asked what the default refresh interval should be.
>>
>> inform Collectors what their default refresh interval is (eg, define 
>> a new standard options template), or re-work (or even remove?) the 

An Exporting Process has a template refresh time in order to satisfy RFC 
5101 / 10.3.6 :

10.3.6.  Template Management

    When IPFIX uses UDP as the transport protocol, Template Sets and
    Option Template Sets MUST be re-sent at regular intervals.  The
    frequency of the (Options) Template transmission MUST be
    configurable.  The default value for the frequency of the (Options)
    Template transmission is 10 minutes.

Meanwhile the Collecting Process follows RFC 5101 / 10.3.7 :

10.3.7.  Collecting Process

    The Collecting Process MUST associate a lifetime with each Template
    (or another definition of an identifier considered unique within the
    Transport Session) received via UDP.  Templates (and similar
    definitions) not refreshed by the Exporting Process within the
    lifetime are expired at the Collecting Process.  If the Template (or
    other definition) is not refreshed before that lifetime has expired,
    the Collecting Process MUST discard that definition and any current
    and future associated Data Records.

Since the CP doesn't know what the EP's template refresh time is, 
perhaps it assumes to follow the "10 minutes" advice in 10.3.6
- and for good measure, it allows three times as much - so, it 
associates a 30 minute lifetime with each template.

However, the EP actually refreshes templates hourly. Or every 90 
minutes. Or daily. Whatever you like, > 30 mins (since, "The frequency 
of the (Options) Template transmission MUST be configurable.").

So both are quite RFC5101 compliant, but fail to interoperate properly - 
because for some period, the CP will have discarded the template and 
won't be able to decode further data until the

P.

---

From: Paul Aitken <[email-masked]>
Date: Sun, 04 Sep 2011 23:10:30 +0100

Benoit,

> 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.

> 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.

> Solution 3: the CP doesn't bother and take a very high value

That seems reasonable. Why not specify this as the default behaviour?

>> Should we have a mechanism which allows an Exporting Process to 
>> report Template lifetimes to the Collecting Process?
>> 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.

P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 5 Sep 2011 08:34:15 +0200

hi Paul, all, 

Comments on the running discussion inline...

Cheers,

Brian

On Sep 5, 2011, at 12:10 AM, Paul Aitken wrote:

>> 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.
> 

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
> 

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... 

> 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.

> 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.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 05 Sep 2011 09:53:33 +0100

Brian,

> 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...

That's rather the point of this thread.

> 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 s…

There may not be any such thing as a "long term" average, since 
templates may come and go at unpredictable times. It may be especially 
difficult to make any predication about the lifetime of short-lived 
templates or frequently redefined templates.

Also, when a template is redefined (ie, same template ID, but different 
fields or different field order), the lifetime calculation has to be 
re-started. Clearly a full discussion is missing and is needed if this 
method is expected to be used.

> 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…

This could work. However, we have to recognise the disadvantage of 
possibly incorrectly decoding some data records where a template 
redefinition has been missed. A finite lifetime would ensure the records 
had to be discarded.

> 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 h…

Clearly there are several ways of solving the problem. I don't really 
mind which method is used, as long as it fills what seems to be a hole 
in IPFIX.

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 5 Sep 2011 12:53:53 +0200

hi, Paul, all,

> That's rather the point of this thread.

Good. Now I'm caught up. :)

> There may not be any such thing as a "long term" average, since templates may come and go at unpredictable times. It may be especially difficult to make any predication about the lifetime of short-lived templates or frequently redefined templates.
> 
> Also, when a template is redefined (ie, same template ID, but different fields or different field order), the lifetime calculation has to be re-started. Clearly a full discussion is missing and is needed if this method is expected to be used.

Ah. Good point... So let's move this down the list for now on account of "effort required to do it right" (indeed, it seems on the face of it that it is harder to do right than the current method, which IMO is impossible to do right, so...)

> This could work. However, we have to recognise the disadvantage of possibly incorrectly decoding some data records where a template redefinition has been missed. A finite lifetime would ensure the records had to be discarded.

I'm still a fan of not even _trying_ to pretend that UDP over a MAC layer that isn't doing some sort of congestion control (even implicit congestion control through "being dedicated and insanely overdimensioned") is reliable enough for every template management corner case (this, indeed, is why IESG pushback put a MUST on IPFIX over SCTP)... If you are going to flow export over UDP, you need to have administrators on _both_ sides of the IPFIX session who know what they're doing, because in limited circumstances things _will_ break, full stop. If you need it to work, don't use the optional protocol, use the mandatory one, where these problems are solved.

> Clearly there are several ways of solving the problem. I don't really mind which method is used, as long as it fills what seems to be a hole in IPFIX.

On that point we are emphatically in agreement.

Cheers,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Tue, 06 Sep 2011 16:15:28 +0200

On 05/09/2011 00:10, 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." ?

Since http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 
mentions it

        4.4.2. UdpExporter Class

     +-------------------------------------+
     | UdpExporter                         |
     +-------------------------------------+   0..1 +------------------+
     | ipfixVersion = 10                   |<>------| TransportLayer-  |
     | sourceIPAddress[0..1]               |        | Security         |
     | destinationIPAddress                |        +------------------+
     | destinationPort = 4739|4740         |
     | ifName/ifIndex[0..1]                |   0..1 +------------------+
     | sendBufferSize {opt.}               |<>------| TransportSession |
     | rateLimit[0..1]                     |        +------------------+
     | maxPacketSize {opt.}                |
     | templateRefreshTimeout = 600        |
     | optionsTemplateRefreshTimeout = 600 |
     | templateRefreshPacket[0..1]         |
     | optionsTemplateRefreshPacket[0..1]  |
     +-------------------------------------+

We could at least add a sentence in RFC5101bis, referring to the 
configuration in draft-ietf-ipfix-configuration-model-10
Something such as:

OLD:

NEW:

    When IPFIX uses UDP as the transport protocol, Template Sets and
    Option Template Sets MUST be re-sent at regular intervals.  The
    frequency of the (Options) Template transmission MUST be
    configurable.  The default value for the frequency of the (Options)
    Template transmission is 10 minutes. Note that the frequency of the
     (Options) Template transmission can be monitored and configured
     with thetemplateRefreshTimeout and optionsTemplateRefreshTimeout
     in [IPFIX-CONF].

I believe this change should be allowed from proposed to draft, as it 
doesn't change the specifications.
The advantage is that it makes an implicit reference to the out of the 
band solution.
Disclaimer: I know it doesn't solve the entire issue, but I'm trying to 
work in the limits imposed by the proposed to draft transition.

Regards, Benoit.