Re: [IPFIX] templateLifePacket on IPFIX collector

"Brian Trammell (IETF)" <> Mon, 02 October 2017 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97110134F50 for <>; Mon, 2 Oct 2017 01:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2s_Im9VpkwsT for <>; Mon, 2 Oct 2017 01:05:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B319134F6C for <>; Mon, 2 Oct 2017 01:05:07 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with ESMTP id 38CEB340D6E; Mon, 2 Oct 2017 10:05:05 +0200 (CEST)
Received: from localhost (localhost []) by localhost (ACF/18338.22211); Mon, 2 Oct 2017 10:05:05 +0200 (CEST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 2 Oct 2017 10:05:04 +0200 (CEST)
Received: from [] (account HELO by (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 31420400; Mon, 02 Oct 2017 10:05:04 +0200
From: "Brian Trammell (IETF)" <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_8F0D05E2-5A70-4957-ABD2-CCF437660961"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 2 Oct 2017 10:05:22 +0200
In-Reply-To: <>
To: Petr Velan <>
References: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [IPFIX] templateLifePacket on IPFIX collector
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Oct 2017 08:05:11 -0000

hi Petr,

This is specified in section 8.4 of RFC 7011 for UDP:

   Since UDP provides no method for reliable transmission of Templates,
   Exporting Processes using UDP as the transport protocol MUST
   periodically retransmit each active Template at regular intervals.
   The Template retransmission interval MUST be configurable via, for
   example, the templateRefreshTimeout and optionsTemplateRefreshTimeout
   parameters as defined in [RFC6728].  Default settings for these
   values are deployment- and application-specific.

For transports with reliable template lifetimes (TCP, SCTP), templates require no refresh, since template state remains synchronized between exporter and collector.



> On 2 Oct 2017, at 09:37, Petr Velan <> wrote:
> Hello IPFIX masters,
> we are implementing an IPFIX collector and a question came up whether to support templateLifePacket configuration as specified in RFC 6728 ( It seems, that the *LifePacket options are not mentioned anywhere else in the IPFIX related documents and that the IPFIX protocol specifies only time based timeout expiration. Therefore, my question is why the *LifePacket options are even present in the RFC 6728 and whether it is necessary to implement them for the collector (and exporter as well) to be compliant with the IPFIX standard.
> I think that the whole *LifePacket option came from NetFlow v9 where the informational RFC 3954 states that:
>       On a regular basis, the Exporter MUST send all the Template
>       Records and Options Template Records to refresh the Collector.
>       Template IDs have a limited lifetime at the Collector and MUST be
>       periodically refreshed.  Two approaches are taken to make sure
>       that Templates get refreshed at the Collector:
>             * Every N number of Export Packets.
>             * On a time basis, so every N number of minutes.
>       Both options MUST be configurable by the user on the Exporter.
>       When one of these expiry conditions is met, the Exporter MUST send
>       the Template FlowSet and Options Template.
> If that is the case, should the IPFIX standard specify something similar as well? Otherwise, it would seem that removing the *LifePacket options from the RFC 6728 would prevent further confusion.
> Kind regards,
> Petr Velan
> _______________________________________________
> IPFIX mailing list