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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 08 June 2017 10:45 UTC

Return-Path: <stewart.bryant@gmail.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 5B1C4129B8C; Thu, 8 Jun 2017 03:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Level:
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FyovXg6wbCjo; Thu, 8 Jun 2017 03:45:16 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A8112EA53; Thu, 8 Jun 2017 03:45:16 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id n195so28236665wmg.1; Thu, 08 Jun 2017 03:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=M/HNc++tejFZFqeUlroBvOF02vYNONirLlso6WKYLww=; b=AT9KD5kKKENAqZ0jhGNzwYo7AeNfLuyK2SBqSN6fWPc8Iofmtq8uy8lvtPnW0hyRFP dsMgdG4Fok8kgSABjDLQs5cRG9K7N9i/Ae6PZ7efiEvy8TwdXItx7NOVYvf54PPc8v2P U0e5OB+hkE7RCW+pRFKuuRYABl0aAkK6vjrjgUobKJLWSM4f+MapNyBYQjxSKyzK+XYV DdUhmaatr0UzZP7r5Bn2CMcAAobURXiRoERrqf8g/MsXPo7xu2MCg7aTwKTiVDsOHm+z nGdPYSV2pZEvRtSVAgoj4i+DBRinG0h9Je0/rs4oejlbkA9+BMTo9HQ3poNiIONhBQlZ YNtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=M/HNc++tejFZFqeUlroBvOF02vYNONirLlso6WKYLww=; b=Byw1FFbl6tib17apvxHyzqL0/Pl8VtlqQwxEK8pl/QS/yZwTseCcWPOOWEfMfcCLoS aru4m+gmyd8hpSvw6wzeURKN7h8glVMsLgNaBdpZr1E3Fre5W/aDFlprLl+xOrjknssd AjLptkAWTwFSP15VC+3bi4V930SchW5KJrPbMCSlWStcTKrqiMMUaw9ZuyG5YRFDXxlX T9lhuqTDEovmFWEp3hzLtLluLD9s3GmJe2iKjkku2+b2rtQr0VhK2c2b5dxZuO9h3Nww MJX2kGfLE9kxzT8qxhFFiaA4a+wVeGBClGFD6WLu9wbTIylsaHLG+7/JHbwqIJWqIzCJ 1UNg==
X-Gm-Message-State: AODbwcC7B01TAiaBviTDjjKEQ4L32DN6NPMl7Z8O/5SzPfZWADdB2U7a iRZtBSpAdAc0OAAGfdA=
X-Received: by 10.28.71.91 with SMTP id u88mr2893911wma.9.1496918714709; Thu, 08 Jun 2017 03:45:14 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i3sm5470986wmb.13.2017.06.08.03.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 03:45:14 -0700 (PDT)
To: li zhenqiang <li_zhenqiang@hotmail.com>, PJ Aitken <pjaitken@brocade.com>, opsawg <opsawg@ietf.org>, idr <idr@ietf.org>, "ipfix@ietf.org" <ipfix@ietf.org>
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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <97e66319-19bf-58f7-8fdc-7a0b62c5caa3@gmail.com>
Date: Thu, 08 Jun 2017 11:45:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <HK2PR0601MB1361B554DA6986285045FE19FCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------C38F4FF222438D3E9955F8A0"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/_JqJ9JCdeiuXPgajXy6kKtE_8ZA>
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: Thu, 08 Jun 2017 10:45:20 -0000

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
>
>     *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 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
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix