Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

[Robert Raszuk <[e-mail]>]

Hey Jakob,

Yes that was exactly my point.

However the fundamental idea around this proposal was to actually reset the
session and trigger withdraw suspecting that the peer is not "feeling
well".

That is unfortunately the problem with completely different deployment
scenarios for BGP which BGP spec so far is trying to treat all in the same
way.

And IMHO the only good way to solve it is to follow what other protocols
did in similar situations and formally define notion of BGP (deployment)
profiles.

What's good for one profile may be pretty bad for the other one (Internet
Tier 1 peer vs stub CE as example). Today such profiles are already in
place except each network creates their own flavor of it. Maybe its time to
simplify BGP deployments and either in IDR or in GROW start work on few key
deployment scenarios where vendors could adjust bgp behaviour with single
per peer profile configuration ?

Thx,
R.








On Sun, Apr 25, 2021 at 8:01 AM Jakob Heitz (jheitz) <[e-mail]>
wrote:

> A long time of TCP zero window does not indicate a data plane
>
> problem, nor a problem with routes received from the stuck peer.
>
> The blockage is in one direction only. The local speaker is unable
>
> to end routes to the stuck peer, but is able to receive routes
>
> from the stuck peer just fine.
>
>
>
> Therefore, I would propose that the response of the local speaker
>
> should be to retain the routes of the stuck peer when it resets the
>
> session, GR style.
>
>
>
> Indications of data plane problems or inability to receive routes from
>
> the stuck peer are separately handled.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, April 24, 2021 2:28 AM
> *To:* Jeffrey Haas <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>; Ben Cox <ben=
> [e-mail]>
> *Subject:* Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback
> requested
>
>
>
> Hi Jeff,
>
>
>
> > So what we are discussing is breaking data plane just because control
> plane
> > has experienced 15 min (or worse recommended 4 min) inability to send
> > keepalives.
>
> A good analogy is the negative impacts of stale routes when you use
> Graceful
> Restart for BGP.  Can you live with the routes in that flavor of stale for
> that long?
>
>
>
> Unfortunately the answer is "it depends". If my stale route is single
> default to the world with working data plane I think the answer is clearly
> YES.
>
>
>
> So that IMHO sort of raises the question if this should be the default
> behaviour.
>
>
>
> Then honestly I am not quite clear how it should be handled on sessions
> which are setup with *draft-ietf-idr-long-lived-gr-00*
>
>
>
> > * Should we perhaps test data plane before declaring peer's failure and
> > before we reset the session ? (I understand that the paramount motivation
> > is BGP consistency here though - but this is one of those cases where one
> > size may not fit all).
>
> In many of these scenarios, BFD or ping would show the interface up.  It's
> the TCP session that is stalled out.
>
>
>
> True.
>
>
>
> I was rather thinking about checking data plane not to the subject peer
> but beyond it (through it). For iBGP - testing next hops. For eBGP some
> known test servers in yr network or in the Internet.
>
>
>
>
>
> > * Should we first withdraw received routes from our peers before
> resetting
> > the session ? At least data plane will have a chance to converge to a
> > different set of links with no sudden packet drops.
>
> Would you describe the drain scenario with the involved parties and what
> the
> congestion state is as part of that?  I don't think I'm understanding the
> above point.
>
>
>
>
>
> If I know I will bring BGP sessions down to you (in any case not only with
> this draft) I should withdraw paths from all of my peers received over such
> session and previously advertised (as best or as add-paths) before
> resetting it. So the control plane clears before we touch the data plane.
> Just to make the end to end reachability with no or minimal data plane
> impact.
>
>
>
>  Thx,
>
> R.
>