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

Robert Raszuk <robert@raszuk.net> Thu, 08 June 2017 11:45 UTC

Return-Path: <rraszuk@gmail.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 64268129405; Thu, 8 Jun 2017 04:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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=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 qNYPbTB8TUUU; Thu, 8 Jun 2017 04:45:35 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 E35DF12EAB1; Thu, 8 Jun 2017 04:45:30 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id m47so123479000iti.1; Thu, 08 Jun 2017 04:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lerdiCA6MJEoqcfXCMI2I922poT+3uZ+0BIlhQ7EH4I=; b=MAYM71hadLwZrYhfXYg5AmrDsXf31zRXdJUZ2n5KjZecYRdiPbrr0BRqmVZZRfvj3v dPahEEXqW7vTStf7SSiO9aZv4EZzREwo/rGo+HUpPxAGMMKCiAfE1d5q4En0NuYOliBi bw8LiWbwGfp9zZGPWwnkEMVinIDogdgF8O88Gc7ZT2z9mWU0U9kzAfHvFp1KlYfG31eJ I0RYvpWp+AHCOViYx+hnEh7F3hxg24XWx8IdtKzZMYLVM4qDI5I3XhMrJzGSaXyru4h4 u1B5p5rKyjqCj8EwH//82ivvfOVMiYBFPBK0gVKCpDsKxJVBuK5MlNjLV+aiZdKWv6Qk 5C7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lerdiCA6MJEoqcfXCMI2I922poT+3uZ+0BIlhQ7EH4I=; b=B8M5UhanL6zVQtiLVSlo3EJ3CfJtuyJwoGJHsPivxJp2OmlY77iQ//BiY2nCNLDK8J QxEkAXf8KCTW3YBwMtetL2+9CoDwQf0v50svP1hPoOQc1rOo+qPJsvBrss6u4KVbDa+t UC+DXtNewFiU7NirmGeCIfu0VUJD7wjLxmlP1ZcjgRHfqDi+dGxM813kzXlbT/MuV2X6 tfU+fJ0+ybkJv/TAjxIKTXvbIin/4r+NulLaQmAsUALEY5j2tEG+Qv+g69mi/FVMNHAg cK6l8HXc4fgCwNd9qqYAunw1IZH+C0N4hYNnK9rdzpYKJk8sJ66CWDXrpBgGP0qAmq/D Ps+A==
X-Gm-Message-State: AODbwcBkXc5b0JSXxnh7NizEZINqjwAmpvLuNG97CPc611AY+Tc+12/P ATcXNduW2uJ8whlCL56ngllbm1gtdQ==
X-Received: by 10.36.48.146 with SMTP id q140mr1336721itq.59.1496922330038; Thu, 08 Jun 2017 04:45:30 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.0.226 with HTTP; Thu, 8 Jun 2017 04:45:29 -0700 (PDT)
In-Reply-To: <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> <HK2PR0601MB1361E3DDD70E9E4FB74B5851FCC90@HK2PR0601MB1361.apcprd06.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 08 Jun 2017 13:45:29 +0200
X-Google-Sender-Auth: 1rndraH_vNq0VGuTUiHwyBb8MQI
Message-ID: <CA+b+ERnXXkkfTvu7oei2MBCXXfo0F1N6TmREBq57i=UjSe2cRg@mail.gmail.com>
To: li zhenqiang <li_zhenqiang@hotmail.com>
Cc: "draft-ietf-idr-bgp-extended-messages.all" <draft-ietf-idr-bgp-extended-messages.all@ietf.org>, idr <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140b17cbd595505517163cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UGGYxVr0dnRY0WOtD0nF5jxWpWU>
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 11:45:37 -0000

Sorry, but MTU is not dependent on the router vendor, but on the circuits
specifications you get from carriers to construct your WAN. Our circuits
(usually emulated ones) are guaranteed to carry 1500 byte packets
regardless of routers used on both ends.

//R

On Thu, Jun 8, 2017 at 11:05 AM, li zhenqiang <li_zhenqiang@hotmail.com>
wrote:

> 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 <robert@raszuk.net>
> *Date:* 2017-06-08 16:30
> *To:* li zhenqiang <li_zhenqiang@hotmail.com>
> *CC:* draft-ietf-idr-bgp-extended-messages.all
> <draft-ietf-idr-bgp-extended-messages.all@ietf.org>; idr <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>
> 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
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Date:* 2017-06-08 14:41
>> *To:* li zhenqiang <li_zhenqiang@hotmail.com>
>> *CC:* draft-ietf-idr-bgp-extended-messages.all
>> <draft-ietf-idr-bgp-extended-messages.all@ietf.org>; idr wg
>> <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> wrote:
>>
>> Hello,
>>
>> This doc, https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ext
>> ended-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
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
>>
>