Re: [IPFIX] template lifetime - proposal

Benoit Claise <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]>
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." ?
>> 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.

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

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

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

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