From nobody Mon Oct 2 00:37:08 2017 Return-Path: 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 8D253134EFD for ; Mon, 2 Oct 2017 00:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6B7m1C8JOXQk for ; Mon, 2 Oct 2017 00:37:04 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0B1134EFB for ; Mon, 2 Oct 2017 00:37:04 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id m198so5741894oig.13 for ; Mon, 02 Oct 2017 00:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=l2FIRyszAvLBMcPnBZqIjkhGDYCJcBhSGQF2n3E7aF4=; b=LoNKDn2YeD60D9vyLZoBJIbhVnBnCLO1zxnU/LQexQ/OyuhB1yziCToBcA8Kk5Qn9w 9MGxpiCgRe9TgbxH0/m8HXqEa8MgSXz7ryQkmKd7JxqXF22uqNIHmZB66rgLhCnPkmmf gNYU3dxbGBo1ts8VY1Zf2IsbL7Nw/OcgXCCS/id2IKbgtd01H+aFnwgqBKb7T+jTG6+m whC4ihOdbG+DhgvsgHLra7F4AlpGTX5RPbVNqqDftvaCU8YbX8cQo3zNcmfGUvMRUrHa j4gvxPkuHZTZq6CIfPTmitWE4OV/kE0idxpvdp4D/nMF242bpI5OTpWl/1G9+GnRg290 PscA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=l2FIRyszAvLBMcPnBZqIjkhGDYCJcBhSGQF2n3E7aF4=; b=A3o+OWezK0eL01j8soWsxO89twaTF3AItAWVQyWaAcSUiC+uMLHG6R18U8RYzO7Qrr 22IjZMZMFI/AYSGeWoR7gRBoJNtNwPj49hK1xi1wPJtWGGywQNiI3AL//bupm+CRrWKK jkG6h1M9illQwSKfBGpdlm8MS6Pxllv/1ZKsx1OHp9dvORFeRTAieP0b8gZVr9jLVHsz Kx7DZA5EdKAWBDD/1s7nH1CirFHDFN+jR3CADf3Tq9k4OeH3LB7LKsUv/6gO8NrDXKpD UKQkjFicitiBKG+dft8eerm8a6JAHRQTdAGyZu3L3J/DrF+Lzp2kBd0/fE375RO7ndXB rsfQ== X-Gm-Message-State: AMCzsaVThsfaINoo6v4rYO123ZLcqyxi7LMHCC6+8LGGMvOiyfJdaRF+ w/DHrDZ4pOV4CP2Kl8Nj1RCbFbXDpJo+5DbHbSQC X-Google-Smtp-Source: AOwi7QDUIv6vDH7OXWro9TBvgrCxNAS6cJZP6Zjax+boMeaAcfIywH8R4PACoHZXgM8dTfB4SG/N/uj4a2r9fTlTUos= X-Received: by 10.202.219.2 with SMTP id s2mr5618858oig.294.1506929823374; Mon, 02 Oct 2017 00:37:03 -0700 (PDT) MIME-Version: 1.0 Sender: thorgrin@gmail.com Received: by 10.58.38.1 with HTTP; Mon, 2 Oct 2017 00:37:03 -0700 (PDT) From: Petr Velan Date: Mon, 2 Oct 2017 09:37:03 +0200 X-Google-Sender-Auth: Fn21WCkBjFZhBbJChER84p0xZPg Message-ID: To: ipfix@ietf.org Content-Type: multipart/alternative; boundary="001a113d5ed8d2e409055a8b709c" Archived-At: Subject: [IPFIX] templateLifePacket on IPFIX collector X-BeenThere: ipfix@ietf.org 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 07:37:06 -0000 --001a113d5ed8d2e409055a8b709c Content-Type: text/plain; charset="UTF-8" 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 --001a113d5ed8d2e409055a8b709c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello IPFIX masters,

we are impleme= nting an IPFIX collector and a question came up whether to support template= LifePacket configuration as specified in RFC 6728 (https://tools.ietf.org/html/rfc6728#s= ection-4.5.2). It seems, that the *LifePacket options are not mentioned= anywhere else in the IPFIX related documents and that the IPFIX protocol s= pecifies 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 *Lif= ePacket option came from NetFlow v9 where the informational RFC 3954 states= that:
      On a regular basis, the Exporter MUST send all the Tem=
plate
      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 sta=
ndard specify something similar as well? Otherwise, it would seem that remo=
ving the *LifePacket options from the RFC 6728 would prevent further confus=
ion.

Kind regards,
Petr Velan

--001a113d5ed8d2e409055a8b709c-- From nobody Mon Oct 2 01:05:12 2017 Return-Path: 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 97110134F50 for ; Mon, 2 Oct 2017 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s_Im9VpkwsT for ; Mon, 2 Oct 2017 01:05:08 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B319134F6C for ; Mon, 2 Oct 2017 01:05:07 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 38CEB340D6E; Mon, 2 Oct 2017 10:05:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.22211); Mon, 2 Oct 2017 10:05:05 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 2 Oct 2017 10:05:04 +0200 (CEST) Received: from [195.176.111.3] (account ietf@trammell.ch HELO public-docking-cx-3449.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 31420400; Mon, 02 Oct 2017 10:05:04 +0200 From: "Brian Trammell (IETF)" Message-Id: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> 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: Cc: ipfix@ietf.org To: Petr Velan References: X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 08:05:11 -0000 --Apple-Mail=_8F0D05E2-5A70-4957-ABD2-CCF437660961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > Hello IPFIX masters, >=20 > 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. >=20 > 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. >=20 >=20 > 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. >=20 > Kind regards, > Petr Velan >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_8F0D05E2-5A70-4957-ABD2-CCF437660961 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlnR80IACgkQihK3vwvq RqNnxRAAm9M0XKMWWhp8HhTMLNWJa9o09fPqA14S34lDL2yICk6mFsy4ktPg1Fgt o3ASZv0hLQYbSKnEMZbTf6XZ++h++Ky+ycyNXScu1fK9GdgXKmBC0qfbJv0Y3UMG fvTlUiGvmlKFP7FkBFz8NjjKp2aetlZaZqAb4Uuo3L+N6c1PCME71XBPBW1X4dK5 JRJoMtZSrUX8+0TNrQxIt1q0PAzRFKAtLdRtnQXUWQzMnVsXDwDde5Oae0HKlCfQ PUT+hARpp7nj/c35DQauZuvX5BYvaIjGlUTsluT6VE/IG/GArsEWJdRXQDAfeETl rjnPWcVFBlK3Keo4RkySGdpXm2KtnGAtmONLAQJz9jKJBgCH143M260CM5GMBeSm PYH+PKB5EDPZI7xQJUt9sVVX9V9E0vaBx66qivqVrmP+8IHuAqhxFCnUhp6bYSGu gJyITb2se1TH3BZWqY60DUjV63m7BQu8Wsi1tkMM8GxtTXt5LxHs9Y+XyeYNAcyP d8gGXqwbcI/gS23bF8aeUOxXapImilWmNyL2eCL+Z7a719nrtCC5+hH/neUbodgZ A21CVf3htikQbiUQlO9zokhtg6Bxi54SZlt986PRaI7/g55wtWtcKLgCqbWJhrCv 5rKic5eoAfTWtoL1Ic2lXA1alIvI3CbRX1PNHU6kgYDp1XSv3aA= =LQaS -----END PGP SIGNATURE----- --Apple-Mail=_8F0D05E2-5A70-4957-ABD2-CCF437660961-- From nobody Mon Oct 2 02:27:06 2017 Return-Path: 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 7D6B613454D for ; Mon, 2 Oct 2017 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wzQ0lx_RNxqH for ; Mon, 2 Oct 2017 02:27:02 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E0013454C for ; Mon, 2 Oct 2017 02:27:01 -0700 (PDT) Received: by mail-oi0-x22a.google.com 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; d=gmail.com; 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; d=1e100.net; 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 10.157.36.35 with SMTP id p32mr7615014ota.25.1506936421238; Mon, 02 Oct 2017 02:27:01 -0700 (PDT) MIME-Version: 1.0 Sender: thorgrin@gmail.com Received: by 10.58.38.1 with HTTP; Mon, 2 Oct 2017 02:27:00 -0700 (PDT) In-Reply-To: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> References: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> 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 , ipfix@ietf.org Content-Type: multipart/alternative; boundary="001a113d058a164b49055a8cfa53" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 09:27:04 -0000 --001a113d058a164b49055a8cfa53 Content-Type: text/plain; charset="UTF-8" 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 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? 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? Cheers, Petr On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) 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 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 > > --001a113d058a164b49055a8cfa53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

I understand th= at the Exporter is required to export the templates at regular intervals. I= t is not clear, whether "regular intervals" mean "time inter= vals" (as suggested by the templateRefreshTimeout example) or if it ca= n mean "packet intervals" as well (as suggested by the RFC 6728).= Moreover, this discusses only the Exporter Processes. My question was prim= arily about the Collecting Process, where the RFC 7011 specifies the follow= ing:

   In order to minimize resource r=
equirements 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 configura= tion model only suggests that the Collecting Process can use the *TemplateL= ifePacket options without actually requiring their implementation anywhere.= Is that correct?

On a related note, while reading through the RFC 6= 728, I've noticed that it still references the obsoleted RFC 5101, whic= h is not good, especially regarding the template timeout on collecting proc= ess. The problem is that it forces the configuration of templateLifeTime an= d optionsTemplateLifeTime options per RFC 5101, Section 10.3.7 where it sta= tes:
   The Collecting Process MUST associa=
te 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 ch= ange?

Cheers,
Petr

On Mon, Oct 2, 2017 at 10:05 AM, Brian Tra= mmell (IETF) <ietf@trammell.ch> wrote:
hi Petr,

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

=C2=A0 =C2=A0Since UDP provides no method for reliable transmission of Temp= lates,
=C2=A0 =C2=A0Exporting Processes using UDP as the transport protocol MUST =C2=A0 =C2=A0periodically retransmit each active Template at regular interv= als.
=C2=A0 =C2=A0The Template retransmission interval MUST be configurable via,= for
=C2=A0 =C2=A0example, the templateRefreshTimeout and optionsTemplateRefresh= Timeout
=C2=A0 =C2=A0parameters as defined in [RFC6728].=C2=A0 Default settings for= these
=C2=A0 =C2=A0values are deployment- and application-specific.

For transports with reliable template lifetimes (TCP, SCTP), templates requ= ire 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> 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 *LifePacke= t options are even present in the RFC 6728 and whether it is necessary to i= mplement 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 t= he informational RFC 3954 states that:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On a regular basis, the Exporter MUST send a= ll the Template
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Records and Options Template Records to refr= esh the Collector.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Template IDs have a limited lifetime at the = Collector and MUST be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0periodically refreshed.=C2=A0 Two approaches= are taken to make sure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that Templates get refreshed at the Collecto= r:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Every N number of Exp= ort Packets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* On a time basis, so e= very N number of minutes.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Both options MUST be configurable by the use= r on the Exporter.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When one of these expiry conditions is met, = the Exporter MUST send
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the Template FlowSet and Options Template. >
>
> If that is the case, should the IPFIX standard specify something simil= ar 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=


--001a113d058a164b49055a8cfa53-- From nobody Mon Oct 2 05:12:00 2017 Return-Path: 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 ; 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 ; 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 ; 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 , "Brian Trammell (IETF)" Cc: ipfix@ietf.org References: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> From: Benoit Claise Message-ID: 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: Content-Type: multipart/alternative; boundary="------------FCAEB6BA4680DF11746B18D4" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:11:58 -0000 This is a multi-part message in MIME format. --------------FCAEB6BA4680DF11746B18D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 ]. 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 ]." 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) > > 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 > 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 > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------FCAEB6BA4680DF11746B18D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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].  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]."
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> 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> 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




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------FCAEB6BA4680DF11746B18D4-- From nobody Mon Oct 2 06:24:23 2017 Return-Path: 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 CA76D132076 for ; Mon, 2 Oct 2017 06:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ca8W7wddAe0s for ; Mon, 2 Oct 2017 06:24:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96E21321DF for ; Mon, 2 Oct 2017 06:24:18 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id y64so8952095oia.7 for ; Mon, 02 Oct 2017 06:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/vA2D1p4oeXO8MdeqR9RSrTUUIKi88XpIp864jZHYP0=; b=tbAS3MOsI53WPOyxA0TqjF4EHsGngrmJwsX2avtSwUJjI6nUCMDy8JW1+p2ohj3piO /rsWAIUE7tyYyCQcXl1xjirZeJ/s2bTSgQR5RADpr2Q96A+3z6f1dILK7JMWmbP1aXXt BufrxJk6qpJ13H20dAbSWXkRH6quAvYRyz5FXvq1BttkxsTt+6A+uhcW0ATG7bpxlEJy GCSmyugzOdRmZIEh/akPBaNluCIOeRVFll16cFNSeB2qXtz+eQXpA3wmD3/7U9U6Cq9i qQv3Qp1udPvOR7MNCpCDREW49v/YFGeL9rPTSzltZWtvvEeZ8/limouYPfrKfMFmrZq7 ERfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/vA2D1p4oeXO8MdeqR9RSrTUUIKi88XpIp864jZHYP0=; b=FF5R7xQ207cL+gu3jiofvDW2gKox8tuFjTtccuJWiYrD0rfS48mQQF2kjF5P66y9JB JUfWqiWhx37biaBeSTlORvH2dODk4ymaxT20FaQxoH/OUGUe7QsgWqINg4PI+Vqt6yte kjGy6M6JwuFtySHRZA0HwSXRKuNsHJOFHWvwXy2jAD0xf5WaemnxE0o3iBFSdWpYn0VT A5G7zaU1z63fJb89yY7axS69mG0xJyo0/psxjwUCn6SC0IhfWkR9IgPGzh79iTmbgxQ2 kD1NCur+8p1+tLsTf1a9C5Uoqi8RBo2OioJXx3jEdNX6xXNEsudzWSou6WML017fsYF5 v9HQ== X-Gm-Message-State: AMCzsaVgNjL1YRfy9eixj5BQxsyK2/YkN+NlKZ+ko5Ic/AtH0AAgDuTc ob1kNx5SfrjfCwRMXtjbHIX8Jk4RDYrM5owh3g== X-Google-Smtp-Source: AOwi7QDg/8Tn2NP1xxbEUJ9ORCeYfftQ4LGjmJI9/mv9xn0/YMiG5+dUcNGsMADqVrijEwfsSIE+3hT2SqCAcZzBpNA= X-Received: by 10.157.86.186 with SMTP id o55mr3964657oth.88.1506950657930; Mon, 02 Oct 2017 06:24:17 -0700 (PDT) MIME-Version: 1.0 Sender: thorgrin@gmail.com Received: by 10.58.38.1 with HTTP; Mon, 2 Oct 2017 06:24:17 -0700 (PDT) In-Reply-To: References: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> From: Petr Velan Date: Mon, 2 Oct 2017 15:24:17 +0200 X-Google-Sender-Auth: J1yX96Iz_sjE5H6pY9y82TEGtJ8 Message-ID: To: Benoit Claise Cc: Petr Velan , "Brian Trammell (IETF)" , ipfix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0e71fca8fb96055a904a33" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:24:22 -0000 --94eb2c0e71fca8fb96055a904a33 Content-Type: text/plain; charset="UTF-8" Hi Benoit, I think that there is a slight confusion. I'm talking specifically about __Collection Process__, not __Exporting Process__. My focus is on templateLifeTime, optionsTemplateLifeTime, templateLifePacket, and optionsTemplateLifePacket options and not at all about templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, and optionsTemplateRefreshPacket options. With that cleared out, let my try to clarify: On Mon, Oct 2, 2017 at 2:11 PM, Benoit Claise wrote: > 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 ]. 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. > > This says that an __Exporting Process__ must implement some kind of the template refresh timeout for UDP and that it must be configurable. However, template lifetime tracking is only suggested for __Collecting Processes__ for the UDP protocol in the RFC 7011 and the template lifepacket expiration is not mentioned at all. My original question was whether the template lifepacket tracking was required/suggested by the IPFIX protocol as it was present in the IPFIX information model. The answer to that question seems to be _no_. > 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 > ]." > 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. > That is a significant change from RFC 5101 which _required_ the template lifetime tracking. The relevant text in RFC 6728 stil references RFC 5101 and suggest that implementing the template lifetime expiration for UDP it is still required for __Collecting Processes_ by the IPFIX protocol, which is no longer true. The template expiration based on number of packets at the __Collecting Process__ was not present anywhere in the RFC 3954. Therefore, I'm surprised to find it in the IPFIX information model when it is not mentioned in the standard. I fully agree that the templateRefreshPacket makes complete sense at the __Exporting Process__, but my focus here is on the __Collecting Process__. Cheers, Petr > > Regards, Benoit > > > Cheers, > Petr > > On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) > 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 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 >> >> > > > _______________________________________________ > IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix > > > --94eb2c0e71fca8fb96055a904a33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benoit,

I think that there is a = slight confusion. I'm talking specifically about __Collection Process__= , not __Exporting Process__. My focus is on templateLifeTime, optionsTempla= teLifeTime, templateLifePacket, and optionsTemplateLifePacket options and n= ot at all about templateRefreshTimeout, optionsTemplateRefreshTimeout, temp= lateRefreshPacket, and optionsTemplateRefreshPacket options.

W= ith that cleared out, let my try to clarify:

On Mon, Oct 2, 2017 at 2:11 PM, Be= noit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Hi Petr,
=20
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:

   I=
n 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 provide=
s 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 [RF=
C6728].  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.

This says that an __Exporting Process__ mus= t implement some kind of the template refresh timeout for UDP and that it m= ust be configurable. However, template lifetime tracking is only suggested = for __Collecting Processes__ for the UDP protocol in the RFC 7011 and the t= emplate lifepacket expiration is not mentioned at all. My original question= was whether the template lifepacket tracking was required/suggested by the= IPFIX protocol as it was present in the IPFIX information model. The answe= r to that question seems to be _no_.
=C2=A0
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]."
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:
   T=
he 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.

That is a significant change from= RFC 5101 which _required_ the template lifetime tracking. The relevant tex= t in RFC 6728=20 stil references RFC 5101 and suggest that implementing the template=20 lifetime expiration for UDP it is still required for __Collecting=20 Processes_ by the IPFIX protocol, which is no longer true.

The temp= late expiration based on number of packets at the __Collecting Process__ wa= s not present anywhere in the RFC 3954. Therefore, I'm surprised to fin= d it in the IPFIX information model when it is not mentioned in the standar= d. I fully agree that the templateRefreshPacket makes complete sense at the= __Exporting Process__, but my focus here is on the __Collecting Process__.=

Cheers,
Petr

Regards, Benoit


Cheers,
Petr

On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
hi Petr,

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

=C2=A0 =C2=A0Since UDP provides no method for reliable transmis= sion of Templates,
=C2=A0 =C2=A0Exporting Processes using UDP as the transport pro= tocol MUST
=C2=A0 =C2=A0periodically retransmit each active Template at re= gular intervals.
=C2=A0 =C2=A0The Template retransmission interval MUST be confi= gurable via, for
=C2=A0 =C2=A0example, the templateRefreshTimeout and optionsTemplateRefreshTimeout
=C2=A0 =C2=A0parameters as defined in [RFC6728].=C2=A0 Default = settings for these
=C2=A0 =C2=A0values 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> 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: >=C2=A0 =C2=A0 =C2=A0 =C2=A0On a regular basis, the Expo= rter MUST send all the Template
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Records and Options Template= Records to refresh the Collector.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Template IDs have a limited = lifetime at the Collector and MUST be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0periodically refreshed.=C2= =A0 Two approaches are taken to make sure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that Templates get refreshed= at the Collector:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Every= N number of Export Packets.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* On a = time basis, so every N number of minutes.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Both options MUST be configu= rable by the user on the Exporter.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When one of these expiry con= ditions is met, the Exporter MUST send
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the Template FlowSet and Opt= ions 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/listin= fo/ipfix



= 

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf=
.org/mailman/listinfo/ipfix


--94eb2c0e71fca8fb96055a904a33-- From nobody Tue Oct 3 01:19:46 2017 Return-Path: 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 C60A6134B82 for ; Tue, 3 Oct 2017 01:19:44 -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 TgPawaPFihQB for ; Tue, 3 Oct 2017 01:19:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1665132D67 for ; Tue, 3 Oct 2017 01:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36751; q=dns/txt; s=iport; t=1507018780; x=1508228380; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+u8C60otfwvIvC7VBEQV6KYVvU2vqx+PJeBp59GvetQ=; b=i+PBnHwo9x/PU9ZJfVGU496I6ThkgqgrtR44RWAKELMu6VW69D9H2+Df ef2HZuhGauxp2Ecp8Itoxr9MW6G2hzSzqXievSqKgmQGJFc4q/J9CAL2z 9pK2BhHY/+Bc9i4uDDIeONNzJzmsez5SwJ5ZKcAeUHsNaMDT1GF5zH0rg w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQDoRtNZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzCBEW4ng3mLE5BmkUaEZg6CAQMKGAEKhRgChQgWAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIUsLBQsJAhggAQYDAgInHxEGDQYCAQGKJAgQh0SdZ4InJ?= =?us-ascii?q?4sLAQEBAQEBAQEBAQEBAQEBAQEBARoFgjd2g1OBaiuCfYRRAQsHAVWCXYJhBYo?= =?us-ascii?q?KiR+FL4hah16DX4koghSJSSSHCIoTg2aHW4E5JgkogQMLMiEIHRVJhGGCPj42A?= =?us-ascii?q?QGHDw8YghwBAQE?= X-IronPort-AV: E=Sophos;i="5.42,473,1500940800"; d="scan'208,217";a="655156751" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2017 08:19:38 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v938JbLV007332; Tue, 3 Oct 2017 08:19:38 GMT To: Petr Velan Cc: "Brian Trammell (IETF)" , ipfix@ietf.org References: <09DB7C34-E8A0-470D-A808-6875AB94FA9A@trammell.ch> From: Benoit Claise Message-ID: <0cfc063d-fbab-0aa6-416f-6f6e203ae865@cisco.com> Date: Tue, 3 Oct 2017 10:19:36 +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: Content-Type: multipart/alternative; boundary="------------3FD27BC85DE50EAC47EA7177" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 08:19:45 -0000 This is a multi-part message in MIME format. --------------3FD27BC85DE50EAC47EA7177 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Petr, > Hi Benoit, > > I think that there is a slight confusion. I'm talking specifically > about __Collection Process__, not __Exporting Process__. My focus is > on templateLifeTime, optionsTemplateLifeTime, templateLifePacket, and > optionsTemplateLifePacket options and not at all about > templateRefreshTimeout, optionsTemplateRefreshTimeout, > templateRefreshPacket, and optionsTemplateRefreshPacket options. > > With that cleared out, let my try to clarify: > > On Mon, Oct 2, 2017 at 2:11 PM, Benoit Claise > wrote: > > 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 ]. 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. > > This says that an __Exporting Process__ must implement some kind of > the template refresh timeout for UDP and that it must be configurable. > However, template lifetime tracking is only suggested for __Collecting > Processes__ for the UDP protocol in the RFC 7011 and the template > lifepacket expiration is not mentioned at all. My original question > was whether the template lifepacket tracking was required/suggested by > the IPFIX protocol as it was present in the IPFIX information model. > The answer to that question seems to be _no_. Expiration on the Exporting Process. From your last sentence in this email, it seems that we agree on the following 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. Could be read as: 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 (packets or time) The Template retransmission interval MUST be configurable via, for example, the templateRefreshTimeout and optionsTemplateRefreshTimeout *or **templateRefreshPacket **and **optionsTemplateRefreshPacket*  parameters as defined in [RFC6728 ] . Default settings for these  values are deployment- and application-specific. Now, I get it that your question is about templateLifeTime, optionsTemplateLifeTime, templateLifePacket, and optionsTemplateLifePacket on the Collecting Process. See below. > 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 > ]." > 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. > > > That is a significant change from RFC 5101 which _required_ the > template lifetime tracking. The relevant text in RFC 6728 stil > references RFC 5101 and suggest that implementing the template > lifetime expiration for UDP it is still required for __Collecting > Processes_ by the IPFIX protocol, which is no longer true. You're right that this functionality moved from a MUST in RFC 5101 to a MAY in RFC7011. You're right that RFC6728 was specified based on RFC5101 What would you change if you would update RFC6728 to be RFC7011? Optional features should still be modeled. So the description text next to templateLifeTime, optionsTemplateLifeTime, templateLifePacket, optionsTemplateLifePacket? So basically, yes, RFC6728 could be updated to be inline with RFC7011. Hence my previous answer "maybe" Regards, Benoit > > The template expiration based on number of packets at the __Collecting > Process__ was not present anywhere in the RFC 3954. Therefore, I'm > surprised to find it in the IPFIX information model when it is not > mentioned in the standard. I fully agree that the > templateRefreshPacket makes complete sense at the __Exporting > Process__, but my focus here is on the __Collecting Process__. > > Cheers, > Petr > > > Regards, Benoit > >> >> Cheers, >> Petr >> >> On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) >> > 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 > > 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 >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > > --------------3FD27BC85DE50EAC47EA7177 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Petr,
Hi Benoit,

I think that there is a slight confusion. I'm talking specifically about __Collection Process__, not __Exporting Process__. My focus is on templateLifeTime, optionsTemplateLifeTime, templateLifePacket, and optionsTemplateLifePacket options and not at all about templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, and optionsTemplateRefreshPacket options.

With that cleared out, let my try to clarify:

On Mon, Oct 2, 2017 at 2:11 PM, Benoit Claise <bclaise@cisco.com> wrote:
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].  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.

This says that an __Exporting Process__ must implement some kind of the template refresh timeout for UDP and that it must be configurable. However, template lifetime tracking is only suggested for __Collecting Processes__ for the UDP protocol in the RFC 7011 and the template lifepacket expiration is not mentioned at all. My original question was whether the template lifepacket tracking was required/suggested by the IPFIX protocol as it was present in the IPFIX information model. The answer to that question seems to be _no_.
Expiration on the Exporting Process. From your last sentence in this email, it seems that we agree on the following
  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.
Could be read as:
  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 (packets or time)
   The Template retransmission interval MUST be configurable via, for
   example, the templateRefreshTimeout and optionsTemplateRefreshTimeout
   or templateRefreshPacket and optionsTemplateRefreshPacket
   parameters as defined in [RFC6728] .  Default settings for these
   values are deployment- and application-specific.
Now, I get it that your question is about templateLifeTime, optionsTemplateLifeTime, templateLifePacket, and optionsTemplateLifePacket on the Collecting Process.
See below.

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]."
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.

That is a significant change from RFC 5101 which _required_ the template lifetime tracking. The relevant text in RFC 6728 stil references RFC 5101 and suggest that implementing the template lifetime expiration for UDP it is still required for __Collecting Processes_ by the IPFIX protocol, which is no longer true.
You're right that this functionality moved from a MUST in RFC 5101 to a MAY in RFC7011.
You're right that RFC6728 was specified based on RFC5101
What would you change if you would update RFC6728 to be RFC7011? Optional features should still be modeled. So the description text next to templateLifeTime, optionsTemplateLifeTime, templateLifePacket, optionsTemplateLifePacket?
So basically, yes, RFC6728 could be updated to be inline with RFC7011. Hence my previous answer "maybe"

Regards, Benoit

The template expiration based on number of packets at the __Collecting Process__ was not present anywhere in the RFC 3954. Therefore, I'm surprised to find it in the IPFIX information model when it is not mentioned in the standard. I fully agree that the templateRefreshPacket makes complete sense at the __Exporting Process__, but my focus here is on the __Collecting Process__.

Cheers,
Petr

Regards, Benoit


Cheers,
Petr

On Mon, Oct 2, 2017 at 10:05 AM, Brian Trammell (IETF) <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> 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




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix



--------------3FD27BC85DE50EAC47EA7177-- From nobody Tue Oct 3 09:17:27 2017 Return-Path: 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 ; 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 ; 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 ; 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 , ipfix@ietf.org References: From: Gerhard Muenz 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: Content-Type: multipart/alternative; boundary="------------EA05DDDD8EA8CA3B9766085E" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:17:26 -0000 This is a multi-part message in MIME format. --------------EA05DDDD8EA8CA3B9766085E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------EA05DDDD8EA8CA3B9766085E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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

--------------EA05DDDD8EA8CA3B9766085E--