IETF Logo Mail Archive

Re: [Idr] BGP Auto-Discovery Protocol State Requirements

heasley <heas@shrubbery.net> Tue, 23 March 2021 18:13 UTC

Return-Path: <heas@shrubbery.net>
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 BFA343A0ECE for <idr@ietfa.amsl.com>; Tue, 23 Mar 2021 11:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 GHt_NhW0pDwA for <idr@ietfa.amsl.com>; Tue, 23 Mar 2021 11:13:16 -0700 (PDT)
Received: from sea.shrubbery.net (sea.shrubbery.net [129.250.47.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9076F3A0EC4 for <idr@ietf.org>; Tue, 23 Mar 2021 11:13:16 -0700 (PDT)
Received: by sea.shrubbery.net (Postfix, from userid 7053) id 13763231EAF; Tue, 23 Mar 2021 18:13:16 +0000 (UTC)
Date: Tue, 23 Mar 2021 18:13:16 +0000
From: heasley <heas@shrubbery.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr@ietf.org" <idr@ietf.org>
Message-ID: <YFovvIX4osJ3TifH@shrubbery.net>
References: <CAOj+MMGndgwqLoV_Un_1Bu3F3xPkg9ZD6=4V5FmYJgQiPD_1yw@mail.gmail.com> <20210319143448.GM29692@pfrc.org> <CAOj+MMFKqpZCyzDbGr0JzZLu7sjEw9NBQ=J9rTqDOuP+Yf1mog@mail.gmail.com> <20210319144657.GO29692@pfrc.org> <CAOj+MME8GB4jo_q3kHm1jx6E60GCHeU-pz0eYy_96BJ+ak7_Bw@mail.gmail.com> <20210319152832.GP29692@pfrc.org> <BYAPR08MB549328E3379E94589DC3CE0885649@BYAPR08MB5493.namprd08.prod.outlook.com> <20210323120515.GA31047@pfrc.org> <CAOj+MMGY+sMHr29Uw4bFct9kxoBnp=fJDULVjvFQL1UxC3JYtQ@mail.gmail.com> <20210323150837.GB31047@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210323150837.GB31047@pfrc.org>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iRIybVabEmDAez4rRmrTUtDCp-I>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Mar 2021 18:13:22 -0000

Tue, Mar 23, 2021 at 11:08:37AM -0400, Jeffrey Haas:
> If a discovered peering session is unacceptable, why would you keep running
> the BGP state machine over and over if it's not going to improve?
> 
> The options we have upon discovering a peer that isn't acceptable are:
> 1. Quiesce the disovered session and require a manual clearing event.
> 2. Keep the instantiated session running even if it never connects.
>    Analogous to explicit configuration of a misconfigured session.
> 3. The discovery protocol itself tells us that the situation has changed.
>    This gives the implementation the option to quiesce without requiring a
>    manual clearing event.

maybe 4. a RFD-like auto-discovered peer connection suppression?

expect each will have propoents.

I do not run a DC, but appreciate your considering the scaling.

v2.23.0 | Report a Bug | By Email