Thank you, Mr. Bryant and Mr. Aitken. SCTP is mandatory for IPFIX, TCP and UDP are optional. SCTP is ok for large IPFIX message because SCTP provides message fragmentation and reassembly method.
According to the discussion in the IDR mail list, TCP is also ok for large IPFIX message. When TCP gets the large message from IPFIX, it cuts the message into segments according to the MTU or MSS of the exporter. TCP itself can not guarentee the segments it emits to the IP small enough to avoid fragmentation, because the MSS or MTU determined by the exporter and collector may be bigger than the MTU in the middle path. Path MTU is not a reliable way neither because the ICMP messages necessary for path MTU detection may be blocked by some nodes in the path. So when fragmentation happens occasionally in practice, the operator has to do something to solve this, such as by configuring the MTU or MSS on the exporter small enough to avoid IP fragmentation. If UDP is used by IPFIX as transport protocol, which means in this case the IPFIX is transaction oriented, it doesn't care about delivery and duplicate protection. So, I think in this case we don't need to provide any fragmentation and reassembly method for IPFIX. Best Regards, [email protected] From: Stewart Bryant Date: 2017-06-08 18:45 To: li zhenqiang; PJ Aitken; opsawg; idr; [email protected] Subject: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX 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/ 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 Date: 2017-06-07 17:53 To: li zhenqiang; opsawg; idr; [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/, extends the maximum update message size of 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 take care to handle the IPFIX message properly, such as only convey as many communities as possible in the IPFIX 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 message space. In this case, it is RECOMMENDED to configure export policy on the exporter to limit the BGP communities to 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 support message splitting. Your comments are appreciated. [email protected] _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
