IETF Logo Mail Archive

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

Claudio Jeker <cjeker@diehard.n-r-g.com> Thu, 04 August 2022 07:14 UTC

Return-Path: <cjeker@diehard.n-r-g.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 DE7D9C15C527 for <idr@ietfa.amsl.com>; Thu, 4 Aug 2022 00:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 vubo-sgqYIYX for <idr@ietfa.amsl.com>; Thu, 4 Aug 2022 00:14:09 -0700 (PDT)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A5DC15C517 for <idr@ietf.org>; Thu, 4 Aug 2022 00:14:07 -0700 (PDT)
Received: (qmail 62504 invoked by uid 1000); 4 Aug 2022 07:14:04 -0000
Date: Thu, 04 Aug 2022 09:14:04 +0200
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: heasley <heas@shrubbery.net>, "idr@ietf. org" <idr@ietf.org>, Job Snijders <job=40fastly.com@dmarc.ietf.org>
Message-ID: <YutxvHezmcPbN45l@diehard.n-r-g.com>
References: <CAOj+MME7XnW7kDXL4muh4Qp1UvabQ9amUoU0Sn3h2axqKzswzA@mail.gmail.com> <77F3E1F0-486F-47DF-ABE4-EFDB9C2FB6D8@gmail.com> <CAOj+MMGR4f3eLEDZY++1m4Lpo9joG4L9OrWbeF6kREn-9a9onA@mail.gmail.com> <c6e44213-7667-0f67-71a4-634411cd102b@foobar.org> <CAOj+MMFajL6E42WCzC0ZqrfSBZjU-0B=ZzmtvCRPkuMzU8z5QA@mail.gmail.com> <Yun6e5jSb0OYZGAX@shrubbery.net> <CAOj+MMFRJr=cs+5DVOp72BVn_j3NgANwNftyj=jRbdsvPpg-wA@mail.gmail.com> <YurtQXcUaUWfgN5w@shrubbery.net> <CAOj+MMF_VqXYETXPZWpnfQRi9FuV5=wMS7G-df+QKRmXEwa6rQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMF_VqXYETXPZWpnfQRi9FuV5=wMS7G-df+QKRmXEwa6rQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pwF_xDCIDi0NWjc8tmnxUTS-Ea4>
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: Thu, 04 Aug 2022 07:14:13 -0000

On Thu, Aug 04, 2022 at 12:08:02AM +0200, Robert Raszuk wrote:
> I am clearly stating there is no bgp messages other then keepalives.
> 
> So yr 10240 bytes / 19 octets msg = 539 messages.
> 
> Those for eBGP send every 20 sec will take: 3 hours.
> 
> The same for iBGP send every 60 sec will take: 9 hours.

These numbers are way better than the current status quo where sessions
were in such a zombie state for weeks (if not months).
Often the situation goes unnoticed until enough routing errors collected
to affect enough traffic to have admins investigate and even then finding
the bad session is not trivial.
 
> - - -
> 
> Side question - Say I am RS peer and I advertised my net which got
> propagated fine to other IX members and my IX fabric connectivity is
> working fine. Do I really want to automatically cut out my site from
> reachability only if RS went wild ?

If a RS goes wild, hopefully that IX did their work and deployed 2
different RS. So yes, I want the connection to the bad RS to be cut,
that's how admins notice that something is broken.
 
> Yes I want to be aware about the problem and carefully plan the fix not
> just to be cut from dataplane reachability. Same for IBGP control plane
> only RRs etc ...

Again, I hope you have more than just one RR in your network. Because you
will get cuts anyway because of this massive single point of failure.

Having software try to limp along for way to long is a bad design choice.
It often causes bigger failures down the road because the whole
network gets into an unexpected catastrophic state that nobody knows how
to handle.


> On Wed, Aug 3, 2022 at 11:48 PM heasley <heas@shrubbery.net> wrote:
> 
> > Wed, Aug 03, 2022 at 11:42:53AM +0200, Robert Raszuk:
> > > If this is just queued keepalives (no BGP churn) then depending on the
> > > buffer size it may take ages to fill ...
> >
> > Again, it can be filled with any bgp messages.  2.5 full (or <1 king size)
> > bgp messages fill the default cisco iosxr send-buffer of 10240 bytes (xr4.0
> > docs; range 4k - 128k).
> >

> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


-- 
:wq Claudio

v2.23.0 | Report a Bug | By Email