Re: [IPFIX] templateLifePacket on IPFIX collector
Petr Velan <[email protected]> Mon, 2 Oct 2017 11:27:00 +0200
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <CALbOe5PArCC8XMgP6VajWRj=q6U4q9dLi8wqrqWOeGa30Mfyog@mail.gmail.com> |
--===============3523716859300426417== Content-Type: multipart/alternative; boundary="001a113d058a164b49055a8cfa53" --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) <[email protected]> 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 <[email protected]> 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 > > --001a113d058a164b49055a8cfa53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div>Hi Brian,<br><br></div>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:<br><br><pre class=3D"gmail-newpage"> 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.<span style=3D"font= -family:arial,helvetica,sans-serif"><br></span></pre>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?<br><br>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:<br><pre class=3D"gmail-newpage"> 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.</pre><br></div>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?<br><br></div>Cheers,<br></div>Petr<br></div><div class=3D"gmail_extra= "><br><div class=3D"gmail_quote">On Mon, Oct 2, 2017 at 10:05 AM, Brian Tra= mmell (IETF) <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">hi Petr,<br> <br> This is specified in section 8.4 of RFC 7011 for UDP:<br> <br> =C2=A0 =C2=A0Since UDP provides no method for reliable transmission of Temp= lates,<br> =C2=A0 =C2=A0Exporting Processes using UDP as the transport protocol MUST<b= r> =C2=A0 =C2=A0periodically retransmit each active Template at regular interv= als.<br> =C2=A0 =C2=A0The Template retransmission interval MUST be configurable via,= for<br> =C2=A0 =C2=A0example, the templateRefreshTimeout and optionsTemplateRefresh= Timeout<br> =C2=A0 =C2=A0parameters as defined in [RFC6728].=C2=A0 Default settings for= these<br> =C2=A0 =C2=A0values are deployment- and application-specific.<br> <br> For transports with reliable template lifetimes (TCP, SCTP), templates requ= ire no refresh, since template state remains synchronized between exporter = and collector.<br> <br> Cheers,<br> <br> Brian<br> <div><div class=3D"h5"><br> <br> > On 2 Oct 2017, at 09:37, Petr Velan <<a href=3D"mailto:petr.velan@c= esnet.cz">[email protected]</a>> wrote:<br> ><br> > Hello IPFIX masters,<br> ><br> > we are implementing an IPFIX collector and a question came up whether = to support templateLifePacket configuration as specified in RFC 6728 (<a hr= ef=3D"https://tools.ietf.org/html/rfc6728#section-4.5.2" rel=3D"noreferrer"= target=3D"_blank">https://tools.ietf.org/html/<wbr>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 *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.<br> ><br> > I think that the whole *LifePacket option came from NetFlow v9 where t= he informational RFC 3954 states that:<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0On a regular basis, the Exporter MUST send a= ll the Template<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Records and Options Template Records to refr= esh the Collector.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Template IDs have a limited lifetime at the = Collector and MUST be<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0periodically refreshed.=C2=A0 Two approaches= are taken to make sure<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that Templates get refreshed at the Collecto= r:<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Every N number of Exp= ort Packets.<br> >=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.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Both options MUST be configurable by the use= r on the Exporter.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0When one of these expiry conditions is met, = the Exporter MUST send<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the Template FlowSet and Options Template.<b= r> ><br> ><br> > 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.<br> ><br> > Kind regards,<br> > Petr Velan<br> ><br> </div></div>> ______________________________<wbr>_________________<br> > IPFIX mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/ipfix" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/ipfix</a>= <br> <br> </blockquote></div><br></div> --001a113d058a164b49055a8cfa53-- --===============3523716859300426417== 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 --===============3523716859300426417==--