[IPFIX] templateLifePacket on IPFIX collector

--===============2569644219446023117==
Content-Type: multipart/alternative; boundary="001a113d5ed8d2e409055a8b709c"

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

<div dir=3D"ltr"><div><div>Hello IPFIX masters,<br><br></div>we are impleme=
nting an IPFIX collector and a question came up whether to support template=
LifePacket configuration as specified in RFC 6728 (<a href=3D"https://tools=
.ietf.org/html/rfc6728#section-4.5.2">https://tools.ietf.org/html/rfc6728#s=
ection-4.5.2</a>). 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.<br><br></div>I think that the whole *Lif=
ePacket option came from NetFlow v9 where the informational RFC 3954 states=
 that:<br><pre>      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.<br><span style=3D"font-fam=
ily:arial,helvetica,sans-serif"><br></span></pre><pre><span style=3D"font-f=
amily:arial,helvetica,sans-serif">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.<br><br></span></pre><pre><span style=3D"font-family:arial,helvetica,sa=
ns-serif">Kind regards,<br></span></pre><pre><span style=3D"font-family:ari=
al,helvetica,sans-serif">Petr Velan<br></span></pre><br></div>

--001a113d5ed8d2e409055a8b709c--


--===============2569644219446023117==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix

--===============2569644219446023117==--