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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 08 June 2017 18:43 UTC

Return-Path: <jheitz@cisco.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 ED366129AB8; Thu, 8 Jun 2017 11:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.533
X-Spam-Level:
X-Spam-Status: No, score=-12.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 OOYk0OnK8ffs; Thu, 8 Jun 2017 11:43:19 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9D0129AB6; Thu, 8 Jun 2017 11:43:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24160; q=dns/txt; s=iport; t=1496947399; x=1498156999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WVVra9MdTmS5H1hfc3iRLOi6r3bfan01JpU3NDq3Psw=; b=Vkzi7FsNK4zlgRyxssPxDsj+oTfeZkvnwLaEAE4dCUH6CRuB9xncJmns 19Q6FkadakrEEhCt7Xuf8WE7YdSbnGdqKI85C5hjculK6DPy34nrH8FMu f3RrzHCqWPw3H//WocH5pNWgSHsoBQKg83TUONnKIcBTzWKmJbY8i0vOz M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DcAADvmTlZ/4MNJK1eGQEBAQEBAQEBAQEBBwEBAQEBgnBpYoENB4NsihiRa4I/hWuNWIIRIQEJhXkCGoJhPxgBAgEBAQEBAQFrKIUYAQEBAQMBASEKQQsQAgEIEQMBAQEoAwICAiULFAkIAgQBDQUIiT9MAxUQsFmCJotrAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGYYUAglhOgVsJFoJcgmEFiVSNNIZ3OwKHJoM3g3+EVYIPgWOOGIkQgjOJJAEfOD9LdBVHhFE2AxyBZXYBAYg7AYEMAQEB
X-IronPort-AV: E=Sophos; i="5.39,315,1493683200"; d="scan'208,217"; a="37379483"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jun 2017 18:43:18 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v58IhIcV016105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Jun 2017 18:43:18 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Jun 2017 13:43:17 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 8 Jun 2017 13:43:17 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: li zhenqiang <li_zhenqiang@hotmail.com>, robert <robert@raszuk.net>
CC: idr <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages.all" <draft-ietf-idr-bgp-extended-messages.all@ietf.org>
Thread-Topic: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
Thread-Index: AQHS4BevexCH10TLJ0yOlljFBaXnJaIbTIjw
Date: Thu, 08 Jun 2017 18:43:17 +0000
Message-ID: <ab7797b7a44d45beb0076bde474658e3@XCH-ALN-014.cisco.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>
In-Reply-To: <HK2PR0601MB136122AB1E4A260A382374BDFCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.147.9]
Content-Type: multipart/alternative; boundary="_000_ab7797b7a44d45beb0076bde474658e3XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/aBy8x_yTfprfhbezl_z81wBsRms>
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 18:43:22 -0000

TCP does not create IP fragments.
TCP splits its data into correctly sized full IP packets.
If you see IP fragments in the network, then it is because of MTU mismatch.
TCP uses Path MTU detection to find the smallest MTU on its path in order to avoid fragmentation.
People often block the ICMP messages necessary for path MTU detection, so it doesn't always work well.
Regardless, the size of the IP packets is unrelated to the BGP message size.

Thanks,
Jakob.

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of li zhenqiang
Sent: Thursday, June 08, 2017 12:14 AM
To: robert <robert@raszuk.net>
Cc: idr <idr@ietf.org>; draft-ietf-idr-bgp-extended-messages.all <draft-ietf-idr-bgp-extended-messages.all@ietf.org>
Subject: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages

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