IETF Logo Mail Archive

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

Gyan Mishra <hayabusagsm@gmail.com> Mon, 15 August 2022 20:04 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 7E428C15258A for <idr@ietfa.amsl.com>; Mon, 15 Aug 2022 13:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_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_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 COTusLU7FQEj for <idr@ietfa.amsl.com>; Mon, 15 Aug 2022 13:04:52 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 51C59C14F744 for <idr@ietf.org>; Mon, 15 Aug 2022 13:04:52 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id 17so7301466pli.0 for <idr@ietf.org>; Mon, 15 Aug 2022 13:04:52 -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=7eD2F0AsoHiT2yeFqbEX3ULuB5FVcYeszXJ+JA+gEY0=; b=R6Y0IMJPibVGosv1mHE80kw/fhZymMa6th87oQIEyfqiaAqTQZQvQ+JzbKVbd6cmj0 NaLaGAQ72Lt6xZdF6LJ6Fq7vVzlQz4Tu/8uLaVyMYVfL/xOLrPAYFLUZf9IPtsn7/zUw EO4uhl1GO7Uta2136AZycuxU+DsLxIatFznivqBaz7y5Hxc0yKWlT0BZkyz2NSMvcZcZ Fyi6ZYFngRluyhAQhboAuoZZfNcYFtRDcLSQePENOxutG+J4cwoux9COfirsksFkyi7P ZWMuxeTwrhPipoZ1ha+jBL2VRqTD40cgaa3yY2q/2QV0c30j+YmvJPzbxDV9mpCgVF5F dfBQ==
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=7eD2F0AsoHiT2yeFqbEX3ULuB5FVcYeszXJ+JA+gEY0=; b=TxxdMIsPnyP1/lli5wnV9MWdjEuc7pey63gAclHd9ZkDpK/9if0n8VuywQ4FgvaR+j ZzkA/WvNCclnYV6TodqQ6IjkjkSv0qTGrhwVaKauIjNCmKuXjLrzOG2tSWl0hwiprOK0 ykIpo88hvqrKPRzBud/IiWL7m5J98w7QJ0m4JLReHRipzd7EcyWUD12N8LPdY5i+dOWj 5DL5LG+5Hi3csjuEZ7WB0NFa6hk8j/MLyyVewd2VZmRxo4bB3IzxYPOH7iLsPVzCQ1Ul yhw9BvC4FAH0EhHl+t+TSi/L2sQDDVzofNKUwx6DoOxVJx1Bh6h5bwPO5cfU2mBAdddn 0jPg==
X-Gm-Message-State: ACgBeo0FR3l6vlU98PjEMdpV2P5jwDALv9XpGdm0tScSg8EaPsJZNb1E NP4qQfgHxhtoURfd6oqRO8BIze244aI17Fu6S/E=
X-Google-Smtp-Source: AA6agR5n1c2yaQpPP9sOHcxbOOCg73iTul/Sv+vO6REFV1wjegCHLW2bXc6AhcxdHDmG06csARhrUlBnHRdMRxklxBU=
X-Received: by 2002:a17:902:ce87:b0:172:65aa:a7af with SMTP id f7-20020a170902ce8700b0017265aaa7afmr9877948plg.128.1660593891158; Mon, 15 Aug 2022 13:04:51 -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> <CABNhwV29kyL_JF3CdXEJj9BWD=9pg1Z1J8tYyZ5UgJo2LFR5fA@mail.gmail.com> <8CB11AF3-AFE0-4A3B-B8E6-C0AD62B9A937@pfrc.org>
In-Reply-To: <8CB11AF3-AFE0-4A3B-B8E6-C0AD62B9A937@pfrc.org>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 15 Aug 2022 16:04:39 -0400
Message-ID: <CABNhwV3kXOVqK=f1=mZnhhDr2fBA94h31f9a6Rj-JZF70aCniw@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffaf7805e64d24a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WKOxIChyQhL2uNFHLiG_lR7zt00>
Subject: Re: [Idr] 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 20:04:56 -0000

Jeff

On Mon, Aug 15, 2022 at 3:49 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Gyan,
>
> On Aug 15, 2022, at 3:29 PM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>     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.
>
>
> Juniper doesn't implement its BGP using versioned tables and doesn't have
> this problem.
>

    Gyan> The versioned table AFAIK is related to the Radix tree and is
used to detect the slow peer as the table version number is different cisco
specific.

The slow peer problem as described is when a router is slow in processing
BGP updates, superset of the overall TCP zero window issue and slow peer
mechanism AFAIK is a method of detecting and mitigation of slow peer that
is having control / management plane  processing issues that could
eventually lead to a TCP zero window state.

>
> -- Jeff
>
> --

<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