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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

> As noted in the thread, the important property a protocol must design for
is
> 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
RFC4271.

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

On Tue, Mar 23, 2021 at 12:43 PM Jeffrey Haas <[e-mail]> 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
>