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

Jeffrey Haas <> Fri, 19 March 2021 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA7B53A141A for <>; Fri, 19 Mar 2021 06:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fLNFwNnV7jV0 for <>; Fri, 19 Mar 2021 06:46:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B545F3A14DD for <>; Fri, 19 Mar 2021 06:46:13 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 994421E446; Fri, 19 Mar 2021 10:07:43 -0400 (EDT)
Date: Fri, 19 Mar 2021 10:07:43 -0400
From: Jeffrey Haas <>
To: Tony Przygienda <>
Cc: "Acee Lindem (acee)" <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Mar 2021 13:46:15 -0000

On Fri, Mar 19, 2021 at 02:36:08PM +0100, Tony Przygienda wrote:
> agreed roughly. I don't have any particular likes or dislikes but observe
> that until you get an agreement on whether you use the Occam's razor of
> "only and only what gets TCP connected" or not amongst yourself you will
> not have an easy time to reach agreement on a specific design

Hence the dt document.  We have 2 (now 2.5) possible solutions to the state
problem.  The proposals analyzed use both of them in different flavors.  The
authors of a proposal should be able to justify why they put the state they
did into them.

The dt document says "this is a problem to be solved".  The WG gets to pick
what solution it likes.

> the mtu observation about packets going over different transport than TCP
> session is pretty good. On IGPs the padding is bit of a kludge (but in a
> sense a good kludge since it checks the "reality" of packets passing), I
> would venture that including MTU & other parameters description in the
> packet to make sure both sides have acceptable things and with 3-way also
> see each other and don't shout two-way only is a better design.

BFD for large packets[1] leverages similar tricks and is intended to be used
as a service.  But much like the observations karp made about crypto,
running even a generic service is problematic based on your bootstrapping

An IGP with MTU detection can protect BGP... if BGP uses an IGP.
BFD can protect multiple services... if BFD gets to come up first - but that
may depend on routing.

-- Jeff