Subject: [IPFIX] templateLifePacket on IPFIX collector

From: Petr Velan <[email-masked]>
Date: Mon, 2 Oct 2017 09:37:03 +0200

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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 2 Oct 2017 10:05:22 +0200

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 <[email-masked]> 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:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Petr Velan <[email-masked]>
Date: Mon, 2 Oct 2017 11:27:00 +0200

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) <[email-masked]>
wrote:

> For transports with reliable template lifetimes (TCP, SCTP), templates
> require no refresh, since template state remains synchronized between
> exporter and collector.
>
> Cheers,
>
> Brian
>
>
> > 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
> >

---

From: Benoit Claise <[email-masked]>
Date: Mon, 2 Oct 2017 14:11:49 +0200

Hi Petr,
> 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.
> primarily about the Collecting Process, where the RFC 7011 specifies 
> the following:
>
> 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

    parameters as defined in [RFC6728 <https://tools.ietf.org/html/rfc6728>].  Default settings for these

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

Now, an editorial errata (more for completeness that anything else) 
could be that RFC7011 should mention RFC 6728 templateRefreshPacket and 
optionsTemplateRefreshPacket.
However, it says "for example, the templateRefreshTimeout and 
optionsTemplateRefreshTimeout parameters as defined in [RFC6728 
<https://tools.ietf.org/html/rfc6728>]."
So there might be other examples.
>
> On a related note, while reading through the RFC 6728, I've noticed 
> that it still references the obsoleted RFC 5101, which is not good, 
> especially regarding the template timeout on collecting process. The 
> problem is that it forces the configuration of templateLifeTime and 
> optionsTemplateLifeTime options per RFC 5101, Section 10.3.7 where it 
> states:
> 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) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     hi Petr,
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hello IPFIX masters,
>     >
>     > we are implementing an IPFIX collector and a question came up
>     whether to support templateLifePacket configuration as specified
>     in RFC 6728 (https://tools.ietf.org/html/rfc6728#section-4.5.2
>     <https://tools.ietf.org/html/rfc6728#section-4.5.2>). It seems,
>     that the *LifePacket options are not mentioned anywhere else in
>     the IPFIX related documents and that the IPFIX protocol specifies
>     only time based timeout expiration. Therefore, my question is why
>     the *LifePacket options are even present in the RFC 6728 and
>     whether it is necessary to implement them for the collector (and
>     exporter as well) to be compliant with the IPFIX standard.
>     >
>     > I think that the whole *LifePacket option came from NetFlow v9
>     where the informational RFC 3954 states that:
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipfix>
>
>
>
>

---

From: Petr Velan <[email-masked]>
Date: Mon, 2 Oct 2017 15:24:17 +0200

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 <[email-masked]> wrote:

> If the collector is the one that configured the templateRefreshTimeout and
> optionsTemplateRefreshTimeout for the Exporter, then it knows this
> 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
> 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

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

>> > we are implementing an IPFIX collector and a question came up whether
>> to support templateLifePacket configuration as specified in RFC 6728 (
>> 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 [email-masked]://www.ietf.org/mailman/listinfo/ipfix
>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 3 Oct 2017 10:19:36 +0200

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 
> On Mon, Oct 2, 2017 at 2:11 PM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> 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).
>>     Moreover, this discusses only the Exporter Processes. My question
>>     was primarily about the Collecting Process, where the RFC 7011
>>     specifies the following:
>>
>>     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
>
>     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

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 <https://tools.ietf.org/html/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.
>>     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:
>>     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
> 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
>>
>>         > we are implementing an IPFIX collector and a question came
>>         up whether to support templateLifePacket configuration as
>>         specified in RFC 6728
>>         (https://tools.ietf.org/html/rfc6728#section-4.5.2
>>         <https://tools.ietf.org/html/rfc6728#section-4.5.2>). It
>>         seems, that the *LifePacket options are not mentioned
>>         anywhere else in the IPFIX related documents and that the
>>         IPFIX protocol specifies only time based timeout expiration.
>>         Therefore, my question is why the *LifePacket options are
>>         even present in the RFC 6728 and whether it is necessary to
>>         implement them for the collector (and exporter as well) to be
>>         compliant with the IPFIX standard.
>>         >
>>         > I think that the whole *LifePacket option came from NetFlow
>>         v9 where the informational RFC 3954 states that:
>>         > 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
>>         >

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 3 Oct 2017 18:17:05 +0200

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:
> 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.
>