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

[Jeffrey Haas <[e-mail]>]

On Tue, Mar 23, 2021 at 06:13:16PM +0000, heasley wrote:
> Tue, Mar 23, 2021 at 11:08:37AM -0400, Jeffrey Haas:
> > If a discovered peering session is unacceptable, why would you keep running
> > the BGP state machine over and over if it's not going to improve?
> > 
> > The options we have upon discovering a peer that isn't acceptable are:
> > 1. Quiesce the disovered session and require a manual clearing event.
> > 2. Keep the instantiated session running even if it never connects.
> >    Analogous to explicit configuration of a misconfigured session.
> > 3. The discovery protocol itself tells us that the situation has changed.
> >    This gives the implementation the option to quiesce without requiring a
> >    manual clearing event.
> 
> maybe 4. a RFD-like auto-discovered peer connection suppression?

The RFC 4271 machinery technically already has this sort of thing.  The two
interacting RFC things are the ConnectRetryTimer and the
DampPeerOscillations feature.

What is partially problematic on the "rely on the existing BGP FSM" is many
people aren't thinking through those timer considerations:

- The recommended value for ConnectRetryTimer is 120s.
- Oscillation damping is intentionally under-specified.  And it's totally
  optional.
- Many implementations (including the one I code for), do not stick to 120s
  values as an initial value.

Operators usually want their sessions to come up promptly.  In a data center
fabric context, how long after discovery are you willing to wait before it
comes up?

What this likely will mean for people's implementations is:
- The initial ManualStart event for the session (since this is coming from
  outside of BGP timer infra) will be shortly after discovery.
- The ConnectRetryTimer is likely to be short.  Oscillations damping is also
  likely to be short, even if it's on a decay cycle that takes it to longer
  values after a small number of rounds.

What this can mean is that the BGP Speaker sending out discovery messages
can expect to be hammered very hard with connection requests.  The listen
socket for a central dispatched listen mechanism will likely overload, which
will cause TCP timers to either go into backpressure modes, or aggressive
implementations that will simply close the socket and trigger the connecting
BGP FSM to back off itself.

Are people going to be happy when their fabric connection takes a few
minutes to Establish?  Probably not.  They'll tweak the timers.

And that's on top of the timers for the auto-discovery mechanism itself and
its reliability mechanisms.  See Section 3.2 in the auto-discovery
considerations draft.

> expect each will have propoents.

It's engineering.  After you've dealt with correctness, you have choices and
you have consequences.

-- Jeff