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

Jeffrey Haas <> Tue, 23 March 2021 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EE6F3A0FF4 for <>; Tue, 23 Mar 2021 04:43:36 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bmXg22rav5Rk for <>; Tue, 23 Mar 2021 04:43:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 49C5C3A0FEF for <>; Tue, 23 Mar 2021 04:43:34 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 844FD1E447; Tue, 23 Mar 2021 08:05:15 -0400 (EDT)
Date: Tue, 23 Mar 2021 08:05:15 -0400
From: Jeffrey Haas <>
To: "Fomin, Sergey (Nokia - US/Mountain View)" <>
Cc: Robert Raszuk <>, "" <>, "Acee Lindem (acee)" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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: Tue, 23 Mar 2021 11:43:36 -0000


On Tue, Mar 23, 2021 at 04:28:17AM +0000, Fomin, Sergey (Nokia - US/Mountain View) wrote:
> > 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. :-)
> Maybe we should revisit the scope definition then?
> I have to agree with Robert on this one.
> Either we are trying to solve a DC underlay discovery use case, or something else.

>From the transport requirements for BGP sessions, what would you subtract
that you think isn't DC specific?

> > Having it in the discovery protocol doesn't impact that if your implementation doesn't want to use it.
> It may bring unnecessary complexity (depending on protocol design). Especially given the “MUST” requirement.
> "The auto-discovery mechanism is designed to be simple.", says section 2.2 of the draft..

The writeup for this thread shows a split: Transport requirements to even
get BGP to come up.  Session parameters either in the discovery protocol, or
discovered when you bring up your BGP FSM and you receive an OPEN.

As noted in the thread, the important property a protocol must design for is
how you handle retries.

> > 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.
> And that might be just fine? Again, if we talk about a DC under a single administrative entity; and expect that other ZTP/configuration provisioning mechanisms are already in-place.

This is a valid opinion.

End of the day, the requirements are motivated by how do you make auto
configuration able to be done.  If the working group decides that certain
types of misconfigurations (and thus less "auto") are acceptable, so be it.
But it won't be done blindly because the issue has not been considered.  You
simply get to justify it to your customers.

-- Jeff