Re: [IPFIX] templateLifePacket on IPFIX collector
Gerhard Muenz <[email protected]> Tue, 3 Oct 2017 18:17:05 +0200
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============6387277685826134038== Content-Type: multipart/alternative; boundary="------------EA05DDDD8EA8CA3B9766085E" Content-Language: en-US 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix --------------EA05DDDD8EA8CA3B9766085E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> Hi Petr,<br> <br> I have read the other replies by Brian and Benoit. Here some additional thoughts from my side.<br> <br> 1) Does an IPFIX collector have to support templateLifePacket?<br> 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.<br> 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.<br> 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.<br> <br> 2) Are the *LifePacket parameters mentioned anywhere else?<br> Yes, in IPFIX-MIB. If you read the parameter description in RFC6728 to the end, you find the hint:<br> "Note that these parameters correspond to ipfixTransportSessionTemplateRefreshPacket and ipfixTransportSessionOptionsTemplateRefreshPacket in the IPFIX MIB module [RFC6615]."<br> <br> 3) Why are the *LifePacket parameters present in RFC6728?<br> Because they are and have been present in the IPFIX-MIB. The goal was to cover IPFIX-MIB as far as possible. <br> <br> Hope this helps.<br> <br> Gerhard<br> <br> <br> <div class="moz-cite-prefix">On 02.10.2017 09:37, Petr Velan wrote:<br> </div> <blockquote type="cite" cite="mid:CALbOe5M7QzMAmvd_mjoa_cqqbAd0idjiXpGbTBp3rtr-McXJNw@mail.gmail.com"> <div dir="ltr"> <div> <div>Hello IPFIX masters,<br> <br> </div> we are implementing an IPFIX collector and a question came up whether to support templateLifePacket configuration as specified in RFC 6728 (<a href="https://tools.ietf.org/html/rfc6728#section-4.5.2" moz-do-not-send="true">https://tools.ietf.org/html/rfc6728#section-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 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.<br> <br> </div> I think that the whole *LifePacket option came from NetFlow v9 where the informational RFC 3954 states that:<br> <pre> 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. <span style="font-family:arial,helvetica,sans-serif"> </span></pre> <pre><span style="font-family:arial,helvetica,sans-serif">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. </span></pre> <pre><span style="font-family:arial,helvetica,sans-serif">Kind regards, </span></pre> <pre><span style="font-family:arial,helvetica,sans-serif">Petr Velan </span></pre> <br> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ IPFIX mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/mailman/listinfo/ipfix</a> </pre> </blockquote> <br> </body> </html> --------------EA05DDDD8EA8CA3B9766085E-- --===============6387277685826134038== 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 --===============6387277685826134038==--