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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
