Re: [IPFIX] templateLifePacket on IPFIX collector

Benoit Claise <bclaise@cisco.com> Mon, 02 October 2017 12:11 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 8EB751345DF for <ipfix@ietfa.amsl.com>; Mon, 2 Oct 2017 05:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 BBEgM3cnpeoK for <ipfix@ietfa.amsl.com>; Mon, 2 Oct 2017 05:11:55 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1A41345D8 for <ipfix@ietf.org>; Mon, 2 Oct 2017 05:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18721; q=dns/txt; s=iport; t=1506946314; x=1508155914; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=YUV3ncpcP2Kyuk6xeAA2i/pbd4SfMgbctZ0LgspZFlc=; b=YGQQcLkbCP2W+qfz8e4oPpBU1mhMKI6ji7vlZiZ6ZvJeFM6wx+cGCRSQ ppNxoMPdTWVS8aEAC/3/h87zDJXvkpDfGgepNDBivDGlDsWZhQxWkuuDi rvqCfvjTx6BkzrmpcW0BUe/AlFCioAkmds96LcY9/voZxcBybzRQjqfPX c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCZK9JZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzCBEW4ng3mLE5BkkG5YhGaCEgoYAQqFGAKEfxcBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQEhSwsFCwkCGCcDAgInHxEGAQwGAgEBiiQIEIcRnWeCJyeLD?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgjd2g1OBaiuCfYRdgzqCYQEEigqJH4U?= =?us-ascii?q?viFqHXoNfiSiCFIlJhyyKE4Nmh1uBOSEBNYEOMiEIHRVJhGGCPj42AQGGdoJDA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.42,469,1500940800"; d="scan'208,217";a="656153104"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 12:11:50 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v92CBnbd019338; Mon, 2 Oct 2017 12:11:49 GMT
To: Petr Velan <petr.velan@cesnet.cz>, "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: ipfix@ietf.org
References: <CALbOe5M7QzMAmvd_mjoa_cqqbAd0idjiXpGbTBp3rtr-McXJNw@mail.gmail.com> <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> <CALbOe5PArCC8XMgP6VajWRj=q6U4q9dLi8wqrqWOeGa30Mfyog@mail.gmail.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <b4c2a214-5e6c-861a-a394-ad26ae42bd21@cisco.com>
Date: Mon, 2 Oct 2017 14:11:49 +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: <CALbOe5PArCC8XMgP6VajWRj=q6U4q9dLi8wqrqWOeGa30Mfyog@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------FCAEB6BA4680DF11746B18D4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/D2vl8S0qPBeSuPRUdaLVKBD4Oa0>
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: Mon, 02 Oct 2017 12:11:58 -0000

Hi Petr,
> 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).
As mentioned, the two options come from NetFlow v9, with UDP.
> Moreover, this discusses only the Exporter Processes. My question was 
> primarily about the Collecting Process, where the RFC 7011 specifies 
> the following:
>
>     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?
Not sure I understand.
 From RFC7011

    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 <https://tools.ietf.org/html/rfc6728>].  Default settings for these
    values are deployment- and application-specific.

If the collector is the one that configured the templateRefreshTimeout 
and optionsTemplateRefreshTimeout for the Exporter, then it knows this 
information. Alternatively, it can try to deduce it.

Now, an editorial errata (more for completeness that anything else) 
could be that RFC7011 should mention RFC 6728 templateRefreshPacket and 
optionsTemplateRefreshPacket.
However, it says "for example, the templateRefreshTimeout and 
optionsTemplateRefreshTimeout parameters as defined in [RFC6728 
<https://tools.ietf.org/html/rfc6728>]."
So there might be other examples.
>
> 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?
Maybe.

Regards, Benoit
>
> Cheers,
> Petr
>
> On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) 
> <ietf@trammell.ch <mailto:ietf@trammell.ch>> wrote:
>
>     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 <petr.velan@cesnet.cz
>     <mailto:petr.velan@cesnet.cz>> 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
>     <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 <mailto:IPFIX@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/ipfix
>     <https://www.ietf.org/mailman/listinfo/ipfix>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix