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

Hi Jeff,

> 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.

> 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..

> 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.

--

Sergey

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Friday, March 19, 2021 8:29 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf.org; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements

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 establishing.

-- Jeff

_______________________________________________

Idr mailing list

Idr@ietf.org<mailto:Idr@ietf.org>

https://www.ietf.org/mailman/listinfo/idr