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

Robert Raszuk <> Tue, 23 March 2021 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F95D3A0CFF for <>; Tue, 23 Mar 2021 06:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4c76YpiP7L0 for <>; Tue, 23 Mar 2021 06:23:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 819193A098D for <>; Tue, 23 Mar 2021 06:23:44 -0700 (PDT)
Received: by with SMTP id b14so13337909lfv.8 for <>; Tue, 23 Mar 2021 06:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1I2rjrC6/jAx8vKAPB3wYynqqUrmjkLK5dqet4omcS4=; b=bv8wSGA64g7+rzO38YF6FLe1jpvVMNz7GUkHBelBkqarOEXVU90xGB0vtt8Q7pJ16T h69tdmihieizA94vEavpcEILYef0gvuwqzNRFtQdvDH5Jz2UhK0tiUlBp5Tm/XKG6a7o pHkeY45+xTFZ6xmJzLUAZ6OVJ7KAqVkbwW9fofKVTo22tdozUmyDnPFTtXJIizNu2CJ2 Tr09FIb1972V8Nfr06OeB/q9djh0C1BF2bFwDb9wLHmgdjaB9954ijMB0OuehiIfAD8Y gGvFfqshQH5jKUyLMASyeVVI5WVZvAA/PjCBk07p453TlFOQIDPX1PD6snhVXRi54KT9 T3oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1I2rjrC6/jAx8vKAPB3wYynqqUrmjkLK5dqet4omcS4=; b=BdSG06MELc8R1xGpIaMTAYvdGKPtMPrnmkZ3+Gd67Nh/78TSRzGn3EYeuUTPcpASpg 0qJbSiVTTqsUUEgbwNTQo7EdiQHtN+gCUzKuhQfA8EvJX3UN7uiwfUuM0v/1pRngk6NZ KRsBkX9qmEqk58yKyCis2u3iQV0vc9dB9cBUyb0VZACmqE6srLnBa0B/hcEkgsAC4vha 3Z4ijazi5MdoHrqkeuq2Ukmcuxci48/qTCm+O1wWmhm+Wtwb9GX+JIn7HRW9Q5EA9uxm TAjn0zNxqby6dIVkejJh7bafs7X09ive90mlef9LF4H2+A+heNIzpWCeztvaNs3/e2gL CMsw==
X-Gm-Message-State: AOAM530sJ+3J3V6FrEUzqydQmgRR3OSnQxD7iMU0VJlpNBOkWdlR4dnV vTkFJrEFcrGfersPaY8I3DLHPRJ/kq+r6+kAb/J8Jw==
X-Google-Smtp-Source: ABdhPJzNWBDFNfygC9xv26dhYSBKOl4TAKxzLtM/YnaVHuQ7xwlRYUmWbzlB/X1CHZZ31pXfR/tZU9gbIJqRSCXSki8=
X-Received: by 2002:a19:651b:: with SMTP id z27mr2518905lfb.517.1616505822521; Tue, 23 Mar 2021 06:23:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Tue, 23 Mar 2021 14:23:32 +0100
Message-ID: <>
To: Jeffrey Haas <>
Cc: "Fomin, Sergey (Nokia - US/Mountain View)" <>, "" <>, "Acee Lindem (acee)" <>
Content-Type: multipart/alternative; boundary="000000000000543f5805be34170a"
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 13:23:49 -0000

Hi Jeff,

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

As this point is being brought back again let's zoom on it a bit here.
Clearly the above indicates changes of "handling retries" to current

So I assume you possess some operational evidence which would lead to
suggest that if peer IP address is learned via auto discovery we need to
apply a different BGP OPEN retry procedure or at least timers then if the
same peer's IP address is pushed by cfg from mgmt station. Can you share
this data ?

If not could you please describe how auto discovered peers would need to
have different BGP FSM then say those configured with mistakes. To me this
difference is not obvious.

Now let's see if the same concerns or observations apply if you limit auto
discovery to *only* same L2 domain.

Last the draft says:

"The auto-discovery mechanism will not replace or conflict with data
exchanged by the BGP FSM, including its OPEN message."

But if you are thinking about modifications of handling BGP session retries
then I guess the above needs to have one exception added.

Then we will see different OPEN behaviour depending if peer got auto
discovered vs provisioned ...

Many thx,

On Tue, Mar 23, 2021 at 12:43 PM Jeffrey Haas <> wrote:

> Sergey,
> 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