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

Robert Raszuk <robert@raszuk.net> Thu, 08 June 2017 08:32 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 7610C129C3F; Thu, 8 Jun 2017 01:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.4
X-Spam-Level:
X-Spam-Status: No, score=-0.4 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 TFYpsZx8Ce4N; Thu, 8 Jun 2017 01:32:00 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 5B4BF129C2B; Thu, 8 Jun 2017 01:30:47 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id m47so121826322iti.1; Thu, 08 Jun 2017 01:30:47 -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=Sva2ouPmoXx3q+1yXpaBuo98EvDNENsHLpg3Gdo8TDM=; b=oSYppqZHlkLnUdzX0eGaVgutJIdkllblpFRsyZNtVDFPW7veyhIUCf6wNMWdxj4lt/ rxrmMGUQSqfIxGLEBnWIdxsCm1cymXFsxByxstMalqS0hjia0kNhGMXNix+2bWq1saev CWSl3bUy6XF8st6d9lLf93Yu29QQ1cwvsezvGratqx+8hBSpR9MBJcEW8pZS5HvB5VWb bc1hhoSN3PoLFWT9B14zqfbOStnIlcDmwr2jHejkYE5XvE8rFthUZHfOPTcpQc24Vb8i Bgfq7XArCnELkUWefo81kDfVQGspYpxDOVEnQGKaXRrgD74NwDl9KOzegxKanGCuwlh4 LK2g==
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=Sva2ouPmoXx3q+1yXpaBuo98EvDNENsHLpg3Gdo8TDM=; b=JCdGytqvmGDSXz98rLPVz4HwUx5XxTWlLrbrfVLpQ360x1RmZOCYPCh9/jUhr/fw1w Jdp7M9LjvzjdKphT3+qN/iuCgoFgFhcQHqdhAk02CrVYPld7DPugpj+Hx/XnfPeZplDf UO1rRq6bybTa6pCwBrNndL+RljbHZ75eFj79i4eex3NzOWlVCBMquvYj19MDfbYhbjwg 4gbCkvy1nMwLtryNnYDtN4mohXdxjrSTuleANqoZABy6bGSrI6CJFhMIRd+KTdjZxo+P Xmyf0bab8/2im5YYac8DhqZWjx4zvozFvyZCgu6mjdQS8kBOOevQypGdccB7XLVZv1Uw 6e2w==
X-Gm-Message-State: AODbwcAuFyFyUJYd/MMq7L6h3BU4G1Pu1pzCGI1+EB2GesbGozWa4gES zRb54AbvyqCRz308ed5hCxyITZFrDQ==
X-Received: by 10.36.178.11 with SMTP id u11mr4569787ite.104.1496910646678; Thu, 08 Jun 2017 01:30:46 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.0.226 with HTTP; Thu, 8 Jun 2017 01:30:46 -0700 (PDT)
In-Reply-To: <HK2PR0601MB136122AB1E4A260A382374BDFCC90@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>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 08 Jun 2017 10:30:46 +0200
X-Google-Sender-Auth: yOMvOPXhAL5IAJUGQC7Ssihn3uM
Message-ID: <CA+b+ER=VF++9g6JRXiCYANAqS8tYr7ak7ikZKzL9F2BUBtmkQw@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="f403045d8fc05b33be05516eabd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eBiH1Q-y8yBSIRtXYjiQBZurMS0>
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 08:32:02 -0000

> 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
>
>
>