Re: [IPFIX] template lifetime - proposal

Benoit Claise <bclaise@cisco.com> Tue, 06 September 2011 14:13 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35D521F8841 for <ipfix@ietfa.amsl.com>; Tue, 6 Sep 2011 07:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level:
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BtBza2faz9v for <ipfix@ietfa.amsl.com>; Tue, 6 Sep 2011 07:13:45 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D063A21F87FC for <ipfix@ietf.org>; Tue, 6 Sep 2011 07:13:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p86EFTKo012538 for <ipfix@ietf.org>; Tue, 6 Sep 2011 16:15:29 +0200 (CEST)
Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p86EFSJ3025244; Tue, 6 Sep 2011 16:15:29 +0200 (CEST)
Message-ID: <4E662B00.8010609@cisco.com>
Date: Tue, 06 Sep 2011 16:15:28 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Paul Aitken <paitken@cisco.com>
References: <4E4CDC92.5000003@cisco.com> <4E60F325.5090602@cisco.com> <4E63F756.1040802@cisco.com>
In-Reply-To: <4E63F756.1040802@cisco.com>
Content-Type: multipart/alternative; boundary="------------090008000701000107000504"
Cc: IETF IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] template lifetime - proposal
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 14:13:46 -0000

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.