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

li zhenqiang <li_zhenqiang@hotmail.com> Wed, 21 June 2017 08:53 UTC

Return-Path: <li_zhenqiang@hotmail.com>
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 0840C131983; Wed, 21 Jun 2017 01:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.855
X-Spam-Level:
X-Spam-Status: No, score=0.855 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 ij1s2kh7wM6U; Wed, 21 Jun 2017 01:53:17 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254047.outbound.protection.outlook.com [40.92.254.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59213131BB5; Wed, 21 Jun 2017 01:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=URwwgaqkfESguAxgKOkCcpFiHCce/srvsrwldJg9quo=; b=IPYjKGjLHmfU4iSPOolSYh6N1Um0JUzFbpBb7vTso6QZYYuU/EzphQnfSoqwSPyt+36L3HS/kKEMqq9QNwuUKCkRuedm+VISITS0oNCSuvOM+5jbRVkYpLyl44OPKeNo5kjv4bA8UJWJ7NngTvPaKSUeHp/t210IpZcRAu29dk04y0Tuu4j8VKxLYPuvu+KWMme8L70uK5pCmJDDAD84LCyXXVXzo+aknQE52H1gDgM0h3+GO/6THUv9guc7+bU38zQh6LPDX2UGZUZtaxO9+owO28p8zf+Viy6xWYYga8UV0HewG4QAQga5jbexJZ81m6RPUfskJLWRvllMY9ZMCw==
Received: from PU1APC01FT061.eop-APC01.prod.protection.outlook.com (10.152.252.51) by PU1APC01HT228.eop-APC01.prod.protection.outlook.com (10.152.253.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1157.12; Wed, 21 Jun 2017 08:53:12 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.58) by PU1APC01FT061.mail.protection.outlook.com (10.152.253.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12 via Frontend Transport; Wed, 21 Jun 2017 08:53:12 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::d580:d440:f9e2:b583]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::d580:d440:f9e2:b583%14]) with mapi id 15.01.1178.023; Wed, 21 Jun 2017 08:53:11 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: opsawg <opsawg@ietf.org>, idr <idr@ietf.org>, "ipfix@ietf.org" <ipfix@ietf.org>
Thread-Topic: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
Thread-Index: AQHS0sec79+PG+QhZkiBAviflUwRGQ==
Date: Wed, 21 Jun 2017 08:53:11 +0000
Message-ID: <HK2PR0601MB1361902BF4348AE36EC186E0FCDA0@HK2PR0601MB1361.apcprd06.prod.outlook.com>
References: <HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80@HK2PR0601MB1361.apcprd06.prod.outlook.com>, <HK2PR0601MB13614AD1610E2FA97C21A682FCC80@HK2PR0601MB1361.apcprd06.prod.outlook.com>, <be981ea3-cc15-09a8-e46a-1fa054059c52@brocade.com>, <HK2PR0601MB1361B554DA6986285045FE19FCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>, <97e66319-19bf-58f7-8fdc-7a0b62c5caa3@gmail.com>, <2017060911571620578287@chinamobile.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:2625D9AD5B9CB312FE99B49080E72E1E97BC43BC316578D7DB3D56C7FE1EB391; UpperCasedChecksum:55A6CE467AC1EEDB9AB3B8B00611FE9D36BCB3228AA94D58994DBE243195B2FD; SizeAsReceived:7675; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ePgNsAdrSRt+mfcY77kRuPRtY9rpR0av]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT228; 7:ze26AjIHaGneL8C2PdMa3ictAWw54A+vcFrmroOo4aCahkjYb+qz1yL2ZaiEi6nWx4uXnTXKETPkauuRm+kYneKTfDBZuLY84RcwInVo0Hp+sBUzAabfxI7PdJHjMuVKjKC2pFlBnui5whuiiR9wZVM1MPRbSaKOeeXZABGLG+4VN4kmhFZsVJwnURhNjs6cmfJ8XguUpMWhD8Fvt80+m2hKtEKZ+oeQ6sbcZp6MhQZHnTvGzIVKS3hQG4baEqzcPfqHRdtT5Dieion7GCgOfGB9JPfe0H0GKPfXhqYuvU1HrJCIL/iPD5FXo580D90I9YWr6Z7Lky+0DfC/l4w6z6xTpXO4PtKMghS3Sr3iJN7j6eeuta32ZrovSFjLKij4o3oSAOSeSo/ABbxUihvPrR0WBjHEnp8D4zt4ydcJ/I2Ig794YqSCqvgvur81X7FRIbh8MbDOpiaJycUSrn7mk7s1p8b93PptiHwURH9dBwT6A8XjMmA3vplBUkcff3uu6tkV3hHoDgBsyqgBFvjPdP2mk40e4Wh/CDfrnUEH1g2GuK85Sb7P4lsDwrwynxoCY0l99wpza7QR0KgZASuhQEcX2umML47jbZOo3/sPtipRa9+1Pk2klqbkz3371W4yMfj+zHJtV7c1fYm/Wegv6LAqIYOsPFIsPuGFSLfS12/7MVgxTDLZhT8CmdiCobUBXJ518Fjj19gWdkt9ygUfZ+Qc0Se7bK0GNNXp1oI2AHijSvo95UH82COFcBf6a+HY19m3B6/+1jxYw2WHGnOykg==
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT228; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-traffictypediagnostic: PU1APC01HT228:
x-ms-office365-filtering-correlation-id: 444c5e3b-aaa6-49ae-aadf-08d4b882f1a0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT228;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:PU1APC01HT228; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PU1APC01HT228;
x-forefront-prvs: 0345CFD558
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361902BF4348AE36EC186E0FCDA0HK2PR0601MB1361_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 08:53:11.7109 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT228
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/JFVRw6ho2I6s59Y-OC7_WSNxYtI>
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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2017 08:53:20 -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/

________________________________
li_zhenqiang@hotmail.com

From: lizhenqiang@chinamobile.com<mailto:lizhenqiang@chinamobile.com>
Date: 2017-06-09 11:57
To: Stewart Bryant<mailto:stewart.bryant@gmail.com>; li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>; PJ Aitken<mailto:pjaitken@brocade.com>; opsawg<mailto:opsawg@ietf.org>; idr<mailto:idr@ietf.org>; ipfix@ietf.org<mailto:ipfix@ietf.org>
Subject: Re: Re: [IPFIX] [Idr] discussion about exporting BGP community information in IPFIX
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,
________________________________
lizhenqiang@chinamobile.com

From: Stewart Bryant<mailto:stewart.bryant@gmail.com>
Date: 2017-06-08 18:45
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>; PJ Aitken<mailto:pjaitken@brocade.com>; opsawg<mailto:opsawg@ietf.org>; idr<mailto:idr@ietf.org>; ipfix@ietf.org<mailto:ipfix@ietf.org>
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/<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,

________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: PJ Aitken<mailto:pjaitken@brocade.com>
Date: 2017-06-07 17:53
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>; opsawg<mailto:opsawg@ietf.org>; idr<mailto:idr@ietf.org>; ipfix@ietf.org<mailto:ipfix@ietf.org>
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.

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

Your comments are appreciated.

________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org<mailto:IPFIX@ietf.org>
https://www.ietf.org/mailman/listinfo/ipfix