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

["Jakob Heitz (jheitz)" <[e-mail]>]

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.