Re: [IPFIX] templateLifePacket on IPFIX collector

Gerhard Muenz <muenz@net.in.tum.de> Tue, 03 October 2017 16:17 UTC

Return-Path: <muenz@net.in.tum.de>
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 29438134F1B for <ipfix@ietfa.amsl.com>; Tue, 3 Oct 2017 09:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLuqSyFyZdWA for <ipfix@ietfa.amsl.com>; Tue, 3 Oct 2017 09:17:23 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC2A13454F for <ipfix@ietf.org>; Tue, 3 Oct 2017 09:17:23 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id E9B0B282D01E; Tue, 3 Oct 2017 18:17:15 +0200 (CEST)
To: Petr Velan <petr.velan@cesnet.cz>, ipfix@ietf.org
References: <CALbOe5M7QzMAmvd_mjoa_cqqbAd0idjiXpGbTBp3rtr-McXJNw@mail.gmail.com>
From: Gerhard Muenz <muenz@net.in.tum.de>
Message-ID: <034fa5f7-742f-1fe7-04d8-b68568c8fc27@net.in.tum.de>
Date: Tue, 3 Oct 2017 18:17:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CALbOe5M7QzMAmvd_mjoa_cqqbAd0idjiXpGbTBp3rtr-McXJNw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------EA05DDDD8EA8CA3B9766085E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/BGCQw5lx3Q9HsjxQdnRD15Cirto>
Subject: Re: [IPFIX] templateLifePacket on IPFIX collector
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 03 Oct 2017 16:17:26 -0000

Hi Petr,

I have read the other replies by Brian and Benoit. Here some additional 
thoughts from my side.

1) Does an IPFIX collector have to support templateLifePacket?
No, just because RFC6728 does not require support of all parameters 
specified in the configuration data model. I do not think that such a 
device exists.
A collector will not support the ExportingProcess class, and an SCTP 
exporter will not support the UdpExporter class etc. The same is applies 
to individual configuration and state parameters.
However, if you support a parameter mentioned in RFC6728, it is a good 
idea to name it and locate it as specified in the configuration model to 
simplify configuration management.

2) Are the *LifePacket parameters mentioned anywhere else?
Yes, in IPFIX-MIB. If you read the parameter description in RFC6728 to 
the end, you find the hint:
"Note that these parameters correspond to 
ipfixTransportSessionTemplateRefreshPacket and 
ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB 
module [RFC6615]."

3) Why are the *LifePacket parameters present in RFC6728?
Because they are and have been present in the IPFIX-MIB. The goal was to 
cover IPFIX-MIB as far as possible.

Hope this helps.

Gerhard


On 02.10.2017 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 
> (https://tools.ietf.org/html/rfc6728#section-4.5.2). 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
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix