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

[Jeffrey Haas <[e-mail]>]

Robert,

On Tue, Mar 23, 2021 at 02:23:32PM +0100, Robert Raszuk wrote:
> > 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 ?

Thanks for this framing, it's exactly the point the WG needs to discuss for
retries.

If a router configures a hundred BGP sessions, it has a hundred that it
expects to deal with.  This includes sessions that fail to connect.  But the
general expectation when you have sessions configured is that you expect
them to connect.

With a discovery protocol, you have at best a rough bound of the number of
interfaces that it is running on.  It may be more.  If the peers aren't
found to be acceptable, they'll continue on indefinitely.

Is that acceptable?  Your argument is roughly that "you asked for it, deal
with the consequences".  

At low scales, it's probably quite fine.  

At high scales, with a central listen socket for incoming sessions, you may
end up exhausting the "backlog" parameter of the socket and result in a
denial of service of legitimate sessions.

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

The distinction is when you instantiate a session for a discovered peer and
when you keep it provisioned vs. quiescieng or deleting it.  Remember,
discovery may be a denial of service on the discovering party as well.

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.

> Now let's see if the same concerns or observations apply if you limit auto
> discovery to *only* same L2 domain.

It's a matter of scale, not scope.

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

The distinction isn't about what to do about a BGP session that has been
created by the discovery mechanism.  It's the fact that a session is created
by the discovery mechanism and whether it's left running in a broken mode or
not.

-- Jeff