IETF Logo Mail Archive

Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages

li zhenqiang <li_zhenqiang@hotmail.com> Thu, 08 June 2017 09:05 UTC

Return-Path: <li_zhenqiang@hotmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE85129B51; Thu, 8 Jun 2017 02:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.873
X-Spam-Level:
X-Spam-Status: No, score=0.873 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_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 gQuFJN9nuFv4; Thu, 8 Jun 2017 02:05:33 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255082.outbound.protection.outlook.com [40.92.255.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4233212943E; Thu, 8 Jun 2017 02:05:33 -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=Gg2HTC5CEcgvfkEy9FeJE/8WdBkuQdy+smKtavbKZh0=; b=JzVtzuEUtmSmttnmzQHd4xHAy5BMks+u5U2ReftVeoIg7kRNuQxlPqi9KlxJGMp/ZA20BHHTjZkmP6Oz2ktZJ75iswqFmV9jsBD5YQ/D9D0imdWOhB4y5R2QxBbD92xbsy4Y3SfPbVxeMUd04OBqo35DGljbKQIlE88pESKYR2gvoUa/15WdVPkSIvRezmVlcbjWGKaYbMuJP57b+wYbOCVN5TwhT2t1j8pVlRO20JrVc5/AQuJyQFnW04OzMcb/s+qOmYSTLkx89N6ZBy00vjHIwZ+ZDpG9UbyVPS3WMPsnK9t7N2A6rvTF5nFXWwoFmA5c/TdnLS/dMyWbn/5UaQ==
Received: from SG2APC01FT006.eop-APC01.prod.protection.outlook.com (10.152.250.56) by SG2APC01HT047.eop-APC01.prod.protection.outlook.com (10.152.251.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Thu, 8 Jun 2017 09:05:30 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.250.60) by SG2APC01FT006.mail.protection.outlook.com (10.152.250.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Thu, 8 Jun 2017 09:05:30 +0000
Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b%14]) with mapi id 15.01.1157.012; Thu, 8 Jun 2017 09:05:30 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: robert <robert@raszuk.net>
CC: "draft-ietf-idr-bgp-extended-messages.all" <draft-ietf-idr-bgp-extended-messages.all@ietf.org>, idr <idr@ietf.org>
Thread-Topic: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
Thread-Index: AQHS4BevexCH10TLJ0yOlljFBaXnJQ==
Date: Thu, 08 Jun 2017 09:05:30 +0000
Message-ID: <HK2PR0601MB1361E3DDD70E9E4FB74B5851FCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>
References: <HK2PR0601MB1361016F598133FDC59C8E1DFCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>, <CA+b+ERmYh5sqFmRwkMDk5JJjxc=YopmRJ76Z6BSXwnZikv1oCQ@mail.gmail.com>, <CA+b+ERkVAFh0n24+dL4LNq2DJaubtW8oeNYg4iTJ1kqpsUQ57Q@mail.gmail.com>, <HK2PR0601MB136122AB1E4A260A382374BDFCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>, <CA+b+ER=VF++9g6JRXiCYANAqS8tYr7ak7ikZKzL9F2BUBtmkQw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:8888C917CFD982FFA22AA03F5A582EFEC1950703CD25ABF8036B2EAE2C05729A; UpperCasedChecksum:391D9FC670B72ED2C52CFC103B4BE24006197B0FDF4328376945B861348255BA; SizeAsReceived:8663; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [vLKWyKcEJJ+Ue4MqJCyJf95YgB5EUGtb]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT047; 24:vefdCnOtiGNyPOvqqIgaH9ho9TYUkDj6/NcTzM0gY52rIbgFJWGAqgVFOtzSuX9nfIlvDF1KqzAY/H62zyI44LD6lh4y6k9ZfK2Sx8hrjtM=; 7:IEfe58hEO8FfKsKiXCEtnvUWXq7LrsU3FEAXm62aiqDBMubaGUukR/8A0ed7N5brPpHkKoJQrYCYwHT+menxSDMlD7mz6QVID/sosdfJl4f9WW96ByehykQ6I5+TG9dInfJFRM3v4gHarVc0Mez5uVoTvtcrkfyyYr70g0JQ7nu7HjdzYgWibdglo1fhKGID3138fHLchzV3y1RjC+XPimGwYY/LGu8qANWpBKlezV0aA5ljybGUq9lfi2qkvcVsAzVv4jEznQFwGwvyixgwcS5CjckgqyHzA+QFNQWaJh95+Q2hxZ2PMwvCmLjw+AT3
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT047; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-traffictypediagnostic: SG2APC01HT047:
x-ms-office365-filtering-correlation-id: d679d9e9-4226-4a91-d90f-08d4ae4d8063
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:SG2APC01HT047;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:SG2APC01HT047; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SG2APC01HT047;
x-forefront-prvs: 0332AACBC3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1361E3DDD70E9E4FB74B5851FCC90HK2PR0601MB1361_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 09:05:30.4888 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT047
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ce0WyvObS9POgsuaKOK5OYd_2xs>
Subject: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2017 09:05:36 -0000

I checked the configurations of some routers  in my product network. The WAN MTU for Juniper's routers is 4484, and 4470 for Huawei's routers.

________________________________
li_zhenqiang@hotmail.com

From: Robert Raszuk<mailto:robert@raszuk.net>
Date: 2017-06-08 16:30
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>
CC: draft-ietf-idr-bgp-extended-messages.all<mailto:draft-ietf-idr-bgp-extended-messages.all@ietf.org>; idr<mailto:idr@ietf.org>
Subject: Re: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
> This issue is specific to BGP extended message

I don't think so. Today max BGP message size is 4K and typical WAN MTU 1500 bytes. So it may get fragmented anyway.

If TCP keeps retransmitting same or resized segment and reaches max retransmissions value the connection will be terminated.

//R.



On Thu, Jun 8, 2017 at 9:14 AM, li zhenqiang <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>> wrote:
Yes, TCP will retransmit the missing data. But IP fragmentation will occur again if the BGP message size isn't cut down. The receiver can't get the missing data.
This issue is specific to BGP extended message because the extended update message may be fragmented by IP when it traverses the network from the source to the destination. BGP messages don't need to be fragmented by IP have no such problem.

Best Regards,
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: Robert Raszuk<mailto:robert@raszuk.net>
Date: 2017-06-08 14:41
To: li zhenqiang<mailto:li_zhenqiang@hotmail.com>
CC: draft-ietf-idr-bgp-extended-messages.all<mailto:draft-ietf-idr-bgp-extended-messages.all@ietf.org>; idr wg<mailto:idr@ietf.org>
Subject: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
Hi,

Wouldn't TCP simply retransmit missing data if drops are accidental ?

If drops are "by design" due to as you said security rules I am afraid such path is not going to carry BGP session.

//RR.




On Jun 8, 2017 07:26, "li zhenqiang" <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>> wrote:
Hello,

This doc, 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. My comment is about its transport. BGP is TCP based and TCP relys on IP to do fragmentation and reassembly if needed. But IP fragmented packets  may be droped by some nodes in the network due to security rules or to improve the tansport preformance.  So sometimes the BGP speakers may not receive some fragmented extended update messgaes. This deployment problem should be considered.

Best Regards,
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

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

v2.23.0 | Report a Bug | By Email