IETF Logo Mail Archive

Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

Gyan Mishra <hayabusagsm@gmail.com> Mon, 15 August 2022 19:29 UTC

Return-Path: <hayabusagsm@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 32945C15258A for <idr@ietfa.amsl.com>; Mon, 15 Aug 2022 12:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyHD7mHk1fUR for <idr@ietfa.amsl.com>; Mon, 15 Aug 2022 12:29:29 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F198AC14CF15 for <idr@ietf.org>; Mon, 15 Aug 2022 12:29:29 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id p125so7406870pfp.2 for <idr@ietf.org>; Mon, 15 Aug 2022 12:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=zowO82/n+LS/vJ33zifgVCTpJvfKdtyFGVFtfXpIhyg=; b=GDAFjSUiygmdvO2Oa64OvbsgZYYuVDxdBMBXA8n2CN8ik6TPJitU11v+LRqtW0CoXj ViwnfFKc0jbexqtVhz66e6RuxctB2N5yLNplbaqMceExeqmA/1meokIMaAkDzhRcLXAs wLfSXV5KZjOGSvw0CkLLSX4mmiuuj/OIJWJlucdTovsmHUa9cXG9lYHdWtX2UJKJ12+N jS79z5OYLwSccX23RcoXqgsb94826+PCVoAsnGLS4hvvSpGIznwDVVMTKYjvcIzpFF/A a9z+nkH6iu1klVscWLAYNoQmnTF+3KnuVaV9a+QrTSzvKzog5enPYPsUw/5tU7ZTETUd /ppQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=zowO82/n+LS/vJ33zifgVCTpJvfKdtyFGVFtfXpIhyg=; b=5b1MsTTIDl8xvJBhjaeBkfQ0DevuoYZkTE4en6cb4VCHog7N1uaJSEyLtSz46rEym7 l2mrYyTcVF+Pq48i2K/nJDQpP9EWnKFM9J0oL+q8po8m96BlN2asUO9K+8QgvGT9wl1p 5iidn2k/9EbMelIUGpiyXWk+S5uzE9dfw77BnUij/hUKrWJWS8NpCpmFp5b502cLX+F+ K+SUqP+fNsPVdknfK1/gzE5SodRfwODLnCxQ3+S5mDh9oQ6ZcFvGCFAlqlXSj6513ZX4 AbmV+dHKANY4rWRtLmvgHCH4wdX4/bp6MR7qfL0Px3olkRkOGnj3xQg/vgjl1lohfykg WbEw==
X-Gm-Message-State: ACgBeo3Aqgq1fKdrxECAgYmkvG4J4y8lwE7FN5sRRes/iSuLkrDbGvEj xIBgew/w4Br9xR0Gz06uUsyEbQrdPof82fn0zt0=
X-Google-Smtp-Source: AA6agR7aS6eDpM6+XpwpNXtOSvS5Wru4rLsxU2mlzbMUDli/Z8YNHV2gZMUTghwK2JL91ayyqHay8/4oZlu2xq5kFY4=
X-Received: by 2002:aa7:93ba:0:b0:52e:3726:c092 with SMTP id x26-20020aa793ba000000b0052e3726c092mr18012958pff.4.1660591769059; Mon, 15 Aug 2022 12:29:29 -0700 (PDT)
MIME-Version: 1.0
References: <165920076221.43110.14224170878306367770@ietfa.amsl.com> <CAMFGGcC19MJ4poutfp_C-=14RjQeNQXgc24vHyXoQsdZLNq5PQ@mail.gmail.com> <CABNhwV0b6ODL8u+VG8aYLRD9vQxwupYQT5DL0wBfZoOx-oCsZg@mail.gmail.com> <CABNhwV2v4h2Sr_jKOUPsr-jdq-SbpD7xOLsazZC8zT3J3os_Ow@mail.gmail.com> <CAOj+MMFxHoZ8=gsF3bHho+CRp3XPo4=2WSp_jAvWSXzFzOr74Q@mail.gmail.com> <Yvo2FEBH6tM3ttKd@diehard.n-r-g.com> <CAOj+MMGTQSOYbd6g55vquzBoE2EEGMu4QSMDpYSTWvFhX4+BHg@mail.gmail.com> <CAEm8Q11M35gp=m2pMjnQ_RnQ4S_Otx4wugwx03QRPDvCzMWcyw@mail.gmail.com> <CAOj+MMEdWr4mnp0Cr9QSQ+Msfb6jHwziu=ttPGhdXUrtgtZqBw@mail.gmail.com> <Yvp3eZ4iDccWNmIR@shrubbery.net> <CAOj+MMFkotZAggSwf64pL0ZxYeDjd_sWpSH2sFZEMhgLnQNS1w@mail.gmail.com>
In-Reply-To: <CAOj+MMFkotZAggSwf64pL0ZxYeDjd_sWpSH2sFZEMhgLnQNS1w@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 15 Aug 2022 15:29:17 -0400
Message-ID: <CABNhwV29kyL_JF3CdXEJj9BWD=9pg1Z1J8tYyZ5UgJo2LFR5fA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>, heasley <heas@shrubbery.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000083045805e64ca687"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_TaXywHU-zE_oyurlvZQWWUrM5g>
Subject: Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 15 Aug 2022 19:29:34 -0000

Hi Robert

On Mon, Aug 15, 2022 at 2:24 PM Robert Raszuk <robert@raszuk.net> wrote:

> Hi John,
>
>
>> > IMHO TCP can detect much better stuck peers (both if TCP probes are
>> still
>> > flowing or not flowing). Naturally TCP should inform BGP about such
>> peers
>> > and drop the stuck sessions. This is exactly what we are suggesting in
>> > respect to adding user timeout when you are OPEN socket as a param.
>>
>> submit your draft.
>>
>> if you want to measure timliness of processing updates, that has to be
>> done in bgp with some kind of acknowledgement (of actual processing, not
>> dequeuing from the socket) message type that does not exist today.
>>
>
>
> Please kindly note that this thread is about detection of stuck peers.
>
> What you are describing is detection of slow peers.
>
> Both are useful, but are very different conditions.
>
> And as far as detection of slow peers this has been implemented in good
> code bases for a long time. It was needed to automatically remove such
> peers from peer/update groups.
>
> It is local to the box and it is an implementation matter of BGP and its
> interaction with TCP. No new protocol extension is required. For more
> details pls see the patent notes:
>
> https://patents.google.com/patent/US9270536B2/en
>
>     The BGP Slow peer solution was never standardized and so Cisco is the
only vendor with this option.  So that is still a gap that maybe worth
standardization.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/119000-technote-bgp-00.html

The feature uses time stamps to detect the slow peer as well as table
version and then puts the peer in a slow peer group.  Maybe a similar
detection mechanism could be used to detect the zero window.


Many thx,
> R.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*

v2.23.0 | Report a Bug | By Email