Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
Stewart Bryant <[email protected]> Thu, 8 Jun 2017 11:45:12 +0100
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <97e66319-19bf-58f7-8fdc-7a0b62c5caa3__6542.77872895381$1496918733$gmane$org@gmail.com> |
This is a multi-part message in MIME format. --===============6024697832348865458== Content-Type: multipart/alternative; boundary="------------C38F4FF222438D3E9955F8A0" Content-Language: en-GB This is a multi-part message in MIME format. --------------C38F4FF222438D3E9955F8A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If you stick with UDP, and there are good reasons to do that, maybe we need a fragmentation shim for UDP? Stewart On 08/06/2017 04:21, li zhenqiang wrote: > Hello Mr. Aitken, > > Thank you very much for your suggestion. > I have no perfect idea now. Extending the length of IPFIX message is a > simple method. But do we need to take the transport protocol into > account? Although SCTP is mandatory, some IPFIX implementations use > TCP or UDP as their transport protocol. SCTP provides message > fragmentation and reassembly method, neithor TCP nor UDP. TCP and UDP > rely on IP to finish this work. IP fragmented packets may be droped by > some nodes in the network due to security rules or to improve the > tansport preformance. For the implementations using TCP or UDP as > their transport protocol, sometimes they may not receive some > fragmented IPFIX messgaes when we extend the message length to 32 > bits. I think BGP protocol with extended message length as defined in > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=> also > has the same issue. I will send a seperate mail in IDR to ask for > their opinions. > > Best Regards, > > ------------------------------------------------------------------------ > [email protected] > > *From:* PJ Aitken <mailto:[email protected]> > *Date:* 2017-06-07 17:53 > *To:* li zhenqiang <mailto:[email protected]>; opsawg > <mailto:[email protected]>; idr <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > *Subject:* Re: [IPFIX] [Idr] discussion about exporting BGP > community information in IPFIX > What IPFIX message splitting method would you propose? Bear in > mind that it must be backwards-compatible with existing collectors > which do not expect message splitting. > > Rather than splitting messages, it might be acceptable simply to > send longer messages. I think this would require a new version of > IPFIX (eg, version 11) with the following modifications: > > * 32-bit Length in the Message Header (cf. RFC 7011 / Figure F) > * 32 bit Field Length in the Field Specifier Format (cf. RFC 7011 > / Figure G) > * 32 bit Length in the Set Header Format (cf. RFC 7011 / Figure I) > > P. > > > On 07/06/17 10:02, li zhenqiang wrote: >> about question 1， the message length. >> A WG >> draft,https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=>, >> extends the maximum update message sizeof BGP beyond 4096 bytes to 65535 bytes. So, >> one IPFIX message may not be sufficient to fit all the >> communities related to a specific flow. BGP speakers >> that support the extended message feature >> SHOULD takecare to handle the IPFIX message properly, such as only convey as many communities as possible in theIPFIX message. The collector that >> receives an IPFIX message with maximum length and BGP communities >> contained in its data set SHOULD be aware of the BGP communities may be truncated due to limited messagespace. In this case, it is RECOMMENDED to configure export policy on the exporter to limit the BGP communitiesto be exported, to export only some specific communities, for example, or not to export some communities. >> >> To solve this problem completely, we should update >> IPFIX Protocol Specification RFC7011 to supportmessage splitting. >> >> Your comments are appreciated. >> >> ------------------------------------------------------------------------ >> [email protected] > > > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix --------------C38F4FF222438D3E9955F8A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>If you stick with UDP, and there are good reasons to do that, maybe we need a fragmentation shim for UDP?<br> </p> <p>Stewart<br> </p> <br> <div class="moz-cite-prefix">On 08/06/2017 04:21, li zhenqiang wrote:<br> </div> <blockquote type="cite" cite="mid:HK2PR0601MB1361B554DA6986285045FE19FCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <style>body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em; }div.foxdiv20170608104116840842 { }body { font-size: 10.5pt; font-family: 微软雅黑; color: rgb(0, 0, 0); line-height: 1.5; }</style> <div>Hello Mr. Aitken,</div> <div><br> </div> <div><span></span>Thank you very much for your suggestion.</div> <div>I have no perfect idea now. Extending the length of IPFIX message is a simple method. But do we need to take the transport protocol into account? Although SCTP is mandatory, some IPFIX implementations use TCP or UDP as their transport protocol. SCTP provides message fragmentation and reassembly method, neithor TCP nor UDP. TCP and UDP rely on IP to finish this work. IP fragmented packets may be droped by some nodes in the network due to security rules or to improve the tansport preformance. For the implementations using TCP or UDP as their transport protocol, sometimes they may not receive some fragmented IPFIX messgaes when we extend the message length to 32 bits. I think BGP protocol with extended message length as defined in <span style="font-size: 10.5pt; line-height: 1.5; background-color: window;"> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=" moz-do-not-send="true" style="font-size: 10.5pt; line-height: 1.5; background-color: window;">https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/</a> also has the same issue. I will send a seperate mail in IDR to ask for their opinions.</div> <div><br> </div> <div>Best Regards,</div> <div><br> </div> <hr style="width: 210px; height: 1px;" size="1" align="left" color="#b5c4df"> <div><span> <div style="MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"> <div><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a></div> </div> </span></div> <blockquote style="margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"> <div> </div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> <div style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"> <div><b>From:</b> <a href="mailto:[email protected]" moz-do-not-send="true">PJ Aitken</a></div> <div><b>Date:</b> 2017-06-07 17:53</div> <div><b>To:</b> <a href="mailto:[email protected]" moz-do-not-send="true">li zhenqiang</a>; <a href="mailto:[email protected]" moz-do-not-send="true"> opsawg</a>; <a href="mailto:[email protected]" moz-do-not-send="true">idr</a>; <a href="mailto:[email protected]" moz-do-not-send="true"> [email protected]</a></div> <div><b>Subject:</b> Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX</div> </div> </div> <div> <div class="FoxDiv20170608104116840842">What IPFIX message splitting method would you propose? Bear in mind that it must be backwards-compatible with existing collectors which do not expect message splitting.<br> <br> Rather than splitting messages, it might be acceptable simply to send longer messages. I think this would require a new version of IPFIX (eg, version 11) with the following modifications:<br> <br> * 32-bit Length in the Message Header (cf. RFC 7011 / Figure F)<br> * 32 bit Field Length in the Field Specifier Format (cf. RFC 7011 / Figure G)<br> * 32 bit Length in the Set Header Format (cf. RFC 7011 / Figure I)<br> <br> P.<br> <br> <br> <div class="moz-cite-prefix">On 07/06/17 10:02, li zhenqiang wrote:<br> </div> <blockquote type="cite" cite="mid:HK2PR0601MB13614AD1610E2FA97C21A682FCC80@HK2PR0601MB1361.apcprd06.prod.outlook.com" style="margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"> <div><span></span>about question 1， the message length. </div> <div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"></span><span style="color: rgb(0, 0, 0); font-size: 10.5pt; line-height: 1.5; background-color: rgba(0, 0, 0, 0);">A WG draft,</span><span style="font-size: 10.5pt; line-height: 1.5; background-color: window;"> </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=" style="font-size: 10.5pt; line-height: 1.5; background-color: window;" moz-do-not-send="true">https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/</a>, <span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">extends the maximum update message size</span><span style="color: rgb(0, 0, 0); font-size: 10.5pt; line-height: 1.5; background-color: rgba(0, 0, 0, 0);"> </span><span style="color: rgb(0, 0, 0); font-size: 10.5pt; line-height: 1.5; background-color: rgba(0, 0, 0, 0);">of BGP beyond 4096 bytes to 65535 bytes.</span><span style="color: rgb(0, 0, 0); font-size: 10.5pt; line-height: 1.5; background-color: rgba(0, 0, 0, 0);"> So, one IPFIX message may not be sufficient to fit all the communities related to a specific flow. BGP speakers </span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">that support the extended message feature SHOULD take<span style="white-space: pre;"> </span></span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">care to handle the IPFIX message properly, such as only convey as many communities as possible in the<span style="white-space: pre;"> </span></span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">IPFIX message. The collector that receives an IPFIX message with maximum length and BGP communities </span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">contained in its data set SHOULD be aware of the BGP communities may be truncated due to limited message<span style="white-space: pre;"> </span></span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">space. In this case, it is RECOMMENDED to configure export policy on the exporter to limit the BGP communities<span style="white-space: pre;"> </span></span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">to be exported, to export only some specific communities, for example, or not to export some communities.</span></div> <div><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;"><br> </span></div> <div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">To solve this problem completely, we should update IPFIX Protocol Specification RFC7011 to support<span style="white-space: pre;"> </span>message splitting.</span></div> <div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br> </span></div> <div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Your comments are appreciated.</span></div> <div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br> </span></div> <hr style="width: 210px; height: 1px;" size="1" align="left" color="#b5c4df"> <div><span> <div style="MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"> <div><a class="moz-txt-link-abbreviated" href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a></div> <span></span></div> </span></div> </blockquote> </div> </div> </blockquote> <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> --------------C38F4FF222438D3E9955F8A0-- --===============6024697832348865458== 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 --===============6024697832348865458==--