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

[Jeffrey Haas <[e-mail]>]

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