Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BFF12EB4D; Wed, 7 Jun 2017 02:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLdAKHSuV7wT; Wed, 7 Jun 2017 02:53:40 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EED129B8D; Wed, 7 Jun 2017 02:53:40 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v579kI17027637; Wed, 7 Jun 2017 02:53:35 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 2ax9rt0u3m-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Jun 2017 02:53:35 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 03:53:32 -0600 Received: from [172.27.212.154] (172.27.212.154) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 11:53:24 +0200 To: li zhenqiang , opsawg , idr , "ipfix@ietf.org" References: From: PJ Aitken Message-ID: Date: Wed, 7 Jun 2017 10:53:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------15A4C26C3A4803534CADE22A" Content-Language: en-GB X-Originating-IP: [172.27.212.154] X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706070162 Archived-At: Subject: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX X-BeenThere: ipfix@ietf.org 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: Wed, 07 Jun 2017 09:53:43 -0000 --------------15A4C26C3A4803534CADE22A Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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 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. > > ------------------------------------------------------------------------ > li_zhenqiang@hotmail.com --------------15A4C26C3A4803534CADE22A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit 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.

--------------15A4C26C3A4803534CADE22A--