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

[Jeffrey Haas <[e-mail]>]

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