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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

While actually I tend to agree with some of your comments I think they are
only valid if we are really talking about "high scales".

"High" in the context of BGP.  (Which to me means at least 1000s)

So tell me (and all of us here) where in the DC fabric you see this high
scale especially if we are only talking here about underlay (as draft
says).

Moreover as BGP is trying to do the IGP job here it may be perhaps useful
to tak a look on how IGPs deal with establishing adjacencies and if our
worries BGP may fall into would be something one needs to also consider
when planning to use link state in the DC fabric.

And that is why IMHO unless we clearly state the scope of this work (for
example to limit it to peers connected on the same L2 link - same L3 subnet
- no over the top transport, directly connected ebgp, ebgp between
loopbacks, no ibgp etc ... ) then I am afraid we will keep a bit of
ping-pong here as each person's view may be in fact correct in the specific
deployment scenario one has in mind for the new functionality under
discussion. Except that the deployment scenarios are very different.

Many thx,
Robert.


On Tue, Mar 23, 2021 at 3:46 PM Jeffrey Haas <[e-mail]> wrote:

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