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

Jeffrey Haas <> Fri, 19 March 2021 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82E643A1823 for <>; Fri, 19 Mar 2021 08:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rOkVGH_Y43Ky for <>; Fri, 19 Mar 2021 08:07:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14F003A1828 for <>; Fri, 19 Mar 2021 08:07:00 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 6005E1E446; Fri, 19 Mar 2021 11:28:32 -0400 (EDT)
Date: Fri, 19 Mar 2021 11:28:32 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: Tony Przygienda <>, "" <>, "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 15:07:14 -0000

On Fri, Mar 19, 2021 at 03:30:12PM +0100, Robert Raszuk wrote:
> The MD5 was in context to auto PE-CE eBGP peering on the RFC4364 VRFs. Not
> DC under the same operations.

The motivation for the broader analysis of auto configuration was to make
sure we don't have to completely reinvent this stuff a second round. :-)

> > The proposal must be able to support GTSM, or no GTSM.
> Respectfully I have a different opinion.  That should be part of
> provisioning the auto peer template. Nothing to do with auto discovery.

Having it in the discovery protocol doesn't impact that if your
implementation doesn't want to use it.  It simply becomes another piece of
conflicting configuration if it doesn't.

If your configuration template doesn't have security configured, but it is
required by the auto-discovery advertiser, your implementation would try to
open a bgp session and that would fail.  Your debugging would show that you
received a discovery message, but that tcp fails to connect.  The same would
be true for GTSM.  For BFD, the BGP session may come up, and then bounce, or
not proceed into Established.

If the parameters are in the discovery message, you don't end up with such
mismatches unless you want them to be forced to a particular setting.  And
even if you have preferences about how the session comes up (e.g. require no
authentication for NSR considerations), you still have information in the
discovery that permits you to find out why the session may not be

-- Jeff