Re: [IPFIX] templateLifePacket on IPFIX collector

[Petr Velan <[e-mail]>]

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 <[e-mail]> 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 <https://tools.ietf.org/html/rfc6728>].  Default settings for these
>    values are deployment- and application-specific.
>
>
> If the collector is the one that configured the templateRefreshTimeout and
> optionsTemplateRefreshTimeout for the Exporter, then it knows this
> information. Alternatively, it can try to deduce it.
>
> 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
> <https://tools.ietf.org/html/rfc6728>]."
> So there might be other examples.
>
>
> On a related note, while reading through the RFC 6728, I've noticed that
> it still references the obsoleted RFC 5101, which is not good, especially
> regarding the template timeout on collecting process. The problem is that
> it forces the configuration of templateLifeTime and optionsTemplateLifeTime
> options per RFC 5101, Section 10.3.7 where it states:
>
>    The Collecting Process MUST associate a lifetime with each Template
>    (or another definition of an identifier considered unique within the
>    Transport Session) received via UDP.  Templates (and similar
>    definitions) not refreshed by the Exporting Process within the
>    lifetime are expired at the Collecting Process.
>
> However, the RFC 7011 obsoletes this (see my first quote) and changes this
> behaviour to optional. Would it make sense to update the RFC 6728 to
> reflect this change?
>
> Maybe.
>

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) <[e-mail]>
> 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 <[e-mail]> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>
>
> _______________________________________________
> IPFIX mailing [e-mail]://www.ietf.org/mailman/listinfo/ipfix
>
>
>