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

li zhenqiang <> Thu, 08 June 2017 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89746129584; Wed, 7 Jun 2017 20:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.844
X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JMkBMgU2tYjR; Wed, 7 Jun 2017 20:22:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A5CC1293DB; Wed, 7 Jun 2017 20:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bz6pdjRtH2LgGxmXNO8UbwLX+71f7ok4d/lqfPKxYNc=; b=Ha/gVFmGh2rfd2UI4R9VpWlCz97KipfWuzdj4NBcjrcv//SACfzIdYr7uFiNHS7sBZ7N1YoZB9SLkmhBUJiD6+U14nEtHCUYsh1qimF082PncoZ7opnQrr2n6ZxcUmKGpuHysscJsPr/uqPEaSn+aeYh2+m6kjOBq+VYkEV1eArye4klZeo6ZiUzx8Na/pJdoCSxf4GVnOKlOIVvxCrsH/VD3j8iPLfvgoqIJjp9u3+VDfkGLNGof/stHw1z1439y+M6u2pqLIdSdaU9Po7+ll+UkNGZ/SKnlTfCGDlTb5t86Cb/vOuLZGP9+AN/rwY3Vf5GFlYFfsXHBrp21KQJ6g==
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1143.11; Thu, 8 Jun 2017 03:21:56 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.11 via Frontend Transport; Thu, 8 Jun 2017 03:21:55 +0000
Received: from ([fe80::2115:a445:9d1f:b88b]) by ([fe80::2115:a445:9d1f:b88b%14]) with mapi id 15.01.1157.012; Thu, 8 Jun 2017 03:21:55 +0000
From: li zhenqiang <>
To: PJ Aitken <>, opsawg <>, idr <>, "" <>
Thread-Topic: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
Thread-Index: AQHS0sec79+PG+QhZkiBAviflUwRGQ==
Date: Thu, 8 Jun 2017 03:21:55 +0000
Message-ID: <>
References: <>, <>, <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-incomingtopheadermarker: OriginalChecksum:6B50896E2EE8E28D9C997C560A11C4B5C5C9B2612EE16BD11293D82C9A099046; UpperCasedChecksum:D9A2CB1484B1437CA78BBE338F5F49C1CA9CBFE6E838A3F17A1CCC7D930AFB2A; SizeAsReceived:8522; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [dM715j7EVgjSpvFvkVk/nBZ++z06wwh1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT062; 24:4CVNJFN8aUh5RQY7XGsRoTrIk2PNj+d8HacNAaFu9+1zXQKr3d+fqFzeSBwPLU6PB8Gbas4Uy31mjh5Txl4HEMuPKx1VC2NhA0aUKDNCwhI=; 7:RNSZg7CfBSVB4C69P1vyrYaGY+aLOBW3HNHZ4ffvfYYoKyMw5vmaMwEvDY4mQ+49UBImP1cqiSviNNM6Zfr4LhLwLriV6q0UdBV0pLjLkLqmHnAtQ/BhzpQXeTwUjaJDDimOT6eIcZwiiL6eOBeJWeuZoH4+opGlNa9WLwN2YqoIDwKlk4pRkHXGA8UEUJCU++pSdouvG4IOh++D0RSdpuoVbfCXXUipxThMQBxWXAZYHsIjcz5syq1tHed0tc9nkjh8kJGVkJHyApEZ0vlwd+iC9lZViz3pPUwYAoHpXiy6FDrdikN55oEGYfIqVbqw
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT062;; FPR:; SPF:None; LANG:en;
x-ms-traffictypediagnostic: HK2APC01HT062:
x-ms-office365-filtering-correlation-id: badf30e1-245f-4b59-b985-08d4ae1d812e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HK2APC01HT062;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HK2APC01HT062; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2APC01HT062;
x-forefront-prvs: 0332AACBC3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361B554DA6986285045FE19FCC90HK2PR0601MB1361_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 03:21:55.7253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT062
Archived-At: <>
Subject: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jun 2017 03:22:03 -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<> also has the same issue. I will send a seperate mail in IDR to ask for their opinions.

Best Regards,


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


On 07/06/17 10:02, li zhenqiang wrote:
about question 1, the message length.
A WG draft,<>uvzvTPplWdQkXERikBo&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.

To solve this problem completely, we should update IPFIX Protocol Specification RFC7011 to support message splitting.

Your comments are appreciated.