Subject: Re: [OPSAWG] [Idr] discussion about exporting BGP community information in IPFIX

From: li zhenqiang <[email-masked]>
Date: Wed, 7 Jun 2017 09:02:55 +0000

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-masked]

From: li zhenqiang<mailto:[email-masked]>
Date: 2017-05-22 14:49
To: opsawg<mailto:[email-masked]>; idr<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Idr] discussion about exporting BGP community information in IPFIX
Hello experts from OPSAWG, IDR and IPFIX,

This mail is to follow up the discussion in the mail lists and face to face meetings.

Since traffic aggregation in BGP community granularity is useful for several applications such as backbone network traffic engineering, https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ introduces new information elements(IEs) in IPFIX to export the BGP community information of a specific traffic flow. At present, this draft only defines the IEs for standard community specified in RFC1997. To solve the following two significant questions raised in the previous meetings and mails, I solicit more comments and solution alternatives.

Question 1: Does one IPFIX message  have enough space to fit all the communities related to a specific flow?
BGP community, including standard, extended, large and community container, is a path  attribute of BGP distributed in an update message. Since the maximum length of one BGP message is 4096  bytes as per RFC4271 and 64K bytes for one IPFIX message as per RFC7011, the answer for this question SHOULD be yes. Howerer, some experts say the specification for BGP message lenth in RFC4271  is out of date. Its length is not limited to 4096 bytes. But I do not know the new specification. Solution alternatives for this question are also welcomed.

Question 2: Do we need to cover other kinds of BGP communities, such as extended, large and community container?
Based on previous discussion, large community defined in RFC8092 will be covered in the next version, since it has the same application purpose as standard community. Till now, we do not reach consensus about extended community defined in RFC4360 and community container defined in https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/. We usually do not use the statistical information based on extended community or community container to do traffic engineering tasks. If you think it is useful to export these two kinds of BGP community informaiton in IPFIX, please show your opinions and application use cases.

Thank you all very much and best regards,

________________________________
[email-masked]

---

From: PJ Aitken <[email-masked]>
Date: Wed, 7 Jun 2017 10:53:20 +0100

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:
> 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.
>
> ------------------------------------------------------------------------
> [email-masked]

---

From: li zhenqiang <[email-masked]>
Date: Thu, 8 Jun 2017 03:21:55 +0000

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,

From: PJ Aitken<mailto:[email-masked]>
Date: 2017-06-07 17:53
To: li zhenqiang<mailto:[email-masked]>; opsawg<mailto:[email-masked]>; idr<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 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.

________________________________
[email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 8 Jun 2017 11:45:12 +0100

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:
> 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,
>
>     *From:* PJ Aitken <mailto:[email-masked]>
>     *Date:* 2017-06-07 17:53
>     *To:* li zhenqiang <mailto:[email-masked]>; opsawg
>     <mailto:[email-masked]>; idr <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     *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:
>
>>     one IPFIX message may not be sufficient to fit all the
>>     communities related to a specific flow. BGP speakers
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 9 Jun 2017 11:57:17 +0800

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-masked]
 
From: Stewart Bryant
Date: 2017-06-08 18:45
To: li zhenqiang; PJ Aitken; opsawg; idr; [email-masked]
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

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-masked]
 
From: PJ Aitken
Date: 2017-06-07 17:53
To: li zhenqiang; opsawg; idr; [email-masked]
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.

P.

[email-masked]

---

From: li zhenqiang <[email-masked]>
Date: Wed, 21 Jun 2017 08:53:11 +0000

A new doc has been submitted to the IETF OPSAWG with the following enhancement. Please take time to review and comment it. Thanks.
1. IEs to export BGP extended community are added.
2. IEs to export BGP large community are added.
3. A separate section is added to discuss the consern about message length.
4. IANA and abstract sections are revised accordingly.
5.The section for BGP community container is TBD. BGP community container has totally different format and application, whether or not it is suitable to contain this section in this doc needs more comments.

The detail information about the new doc is as follows.

 Title           : Export BGP community information in IP Flow Information Export (IPFIX)
 Authors         : Zhenqiang Li
                          Rong Gu
                          Jie Dong
Filename        : draft-ietf-opsawg-ipfix-bgp-community-02.txt
Pages           : 17
Date            : 2017-06-20

Abstract:
   This draft introduces several information elements in IPFIX
   information model [RFC7012] to enable IPFIX [RFC7011] to export the
   BGP community information, including standard community defined in
   [RFC1997], extended community defined in [RFC4360], large community
   defined in [RFC8092], community container defined in
   [I-D.ietf-idr-wide-bgp-communities].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-02
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp-community-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-bgp-community-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

From: [email-masked]<mailto:[email-masked]>
Date: 2017-06-09 11:57
To: Stewart Bryant<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; PJ Aitken<mailto:[email-masked]>; opsawg<mailto:[email-masked]>; idr<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
Thank you, Mr. Bryant and Mr. Aitken.

Best Regards,

From: Stewart Bryant<mailto:[email-masked]>
Date: 2017-06-08 18:45
To: li zhenqiang<mailto:[email-masked]>; PJ Aitken<mailto:[email-masked]>; opsawg<mailto:[email-masked]>; idr<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX

Stewart

Best Regards,

P.

_______________________________________________
IPFIX mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipfix