Re: [IPFIX] templateLifePacket on IPFIX collector

Petr Velan <> Mon, 02 October 2017 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D6B613454D for <>; Mon, 2 Oct 2017 02:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wzQ0lx_RNxqH for <>; Mon, 2 Oct 2017 02:27:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3E0013454C for <>; Mon, 2 Oct 2017 02:27:01 -0700 (PDT)
Received: by with SMTP id q133so2241020oic.12 for <>; Mon, 02 Oct 2017 02:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jew9efryc8u54L4V5pIRISWZeg/cveJFg063vbNTuiE=; b=iu9Pk7C/3tRUiTAdsf9ARbrU87F079CJhupochHSd3abBIWq7J6JzagtIysi0iTrR9 G7yxmUz5mGexh6r88LObIe1Y5+qMy+12KrCGNqEr+iMO2Nl21pw9Wdf0JIRJc6kKPnOu bmd4yKrn5ZP3RUoxQ8DmMYfLdSGQ44eMtixCJeiTuBvzHzOqqrNPVImJnWgFI9rJdbFA ENGGmQhFeLPh+bYb90fJRnvvVYd4m/9jepYEL6MtREypm9VcPuO4NFpRDQidvafDvy+V YGYgRTDINCPC3BLH9LW27ECdyalMFZs/I7yVG8M9Fc7Prb5l9q+SYpyG4DWNierxYWHx buLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jew9efryc8u54L4V5pIRISWZeg/cveJFg063vbNTuiE=; b=ky/0YJIdcPkmVd61jijN8DS1q3rQ2y1QCZpsuFfSGXmmj9+beURUpj4P0Ndl+nGT62 iDWdCpvQsUn06/n0JXvaX4+rAmO4vEL+jjZ15z6K0CjPE9EyoeEVUQRxl10Fhd5uUVac RDiDBMxtOFJqvGXiFh0WckjxymY4GR2ZMJXAgfQfVyWOKcxEzYNFBWfui7XBmhyaJgon 9H62c3NlcoKBUSeWF2ANFjU6v9AxIh6HBYo60p7P6v6W2OSz+Wtg+pATpkFyNtow7CYv m4o6Tlm70VICW1oqlYGNqJq9/2jiityKnY19xIuqazDp3b78B4ZQSmTwLPgVwGBIJUPt bo3Q==
X-Gm-Message-State: AMCzsaVG7TywbNFaDEl8xHtIWasPWGB9rlTj/Ehq6EzSNmAKcc3MlutI 2KotKA/gzJyw2AZndY4A2hoZ1vIy54KlXYPRqw==
X-Google-Smtp-Source: AOwi7QBhHlpiWEwp/burYdaEOptNnfhgeX6p5MzjdPoT1uhDSXOKVujSkhgiwaOnxl6msF6akOrTz5tZgrD0Px0hU+w=
X-Received: by with SMTP id p32mr7615014ota.25.1506936421238; Mon, 02 Oct 2017 02:27:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Oct 2017 02:27:00 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Petr Velan <>
Date: Mon, 2 Oct 2017 11:27:00 +0200
X-Google-Sender-Auth: gt-bTYjrwS3r940aJxnRV_EDWEk
Message-ID: <>
To: "Brian Trammell (IETF)" <>
Cc: Petr Velan <>,
Content-Type: multipart/alternative; boundary="001a113d058a164b49055a8cfa53"
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 09:27:04 -0000

Hi Brian,

I understand that the Exporter is required to export the templates at
regular intervals. It is not clear, whether "regular intervals" mean "time
intervals" (as suggested by the templateRefreshTimeout example) or if it
can mean "packet intervals" as well (as suggested by the RFC 6728).
Moreover, this discusses only the Exporter Processes. My question was
primarily about the Collecting Process, where the RFC 7011 specifies the

   In order to minimize resource requirements for Templates that are no
   longer being used by the Exporting Process, the Collecting Process
   MAY associate a lifetime with each Template received in a Transport
   Session.  Templates not refreshed by the Exporting Process within the
   lifetime can then be discarded by the Collecting Process.  The
   Template lifetime at the Collecting Process MAY be exposed by a
   configuration parameter or MAY be derived from observation of the
   interval of periodic Template retransmissions from the Exporting
   Process.  In this latter case, the Template lifetime SHOULD default
   to at least 3 times the observed retransmission rate.

So the IPFIX configuration model only suggests that the Collecting Process
can use the *TemplateLifePacket options without actually requiring their
implementation anywhere. Is that correct?

On a related note, while reading through the RFC 6728, I've noticed that it
still references the obsoleted RFC 5101, which is not good, especially
regarding the template timeout on collecting process. The problem is that
it forces the configuration of templateLifeTime and optionsTemplateLifeTime
options per RFC 5101, Section 10.3.7 where it states:

   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.

However, the RFC 7011 obsoletes this (see my first quote) and changes this
behaviour to optional. Would it make sense to update the RFC 6728 to
reflect this change?


On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) <>

> 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.
> Cheers,
> Brian
> > 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
> >
> >