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

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

This is just "the other way" to cause graceful restart on the peer.
One way is to send it RST. The other way is to send it a new session.
BGP_ID same or different doesn't matter. It's a collision either way.

As you point out Tom, if the peer does not have GR enabled, then the
new session doesn't work.

We must send it a new session anyway. The preceding RST makes sure that
the new session works.

Regards,
Jakob.

-----Original Message-----
From: tom petch <[e-mail]> 
Sent: Wednesday, April 28, 2021 9:02 AM
To: Robert Raszuk <[e-mail]>; Jakob Heitz (jheitz) <[e-mail]>
Cc: idr@ietf. org <[e-mail]>; Ben Cox <ben=[e-mail]>
Subject: Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

From: Idr <[e-mail]> on behalf of Robert Raszuk <[e-mail]>
Sent: 28 April 2021 11:25

I think the default should be a long timer and to retain the routes
when resetting the session. However, this choice should be configurable.

There could be potentially another option ...

Once we can not write to a peer over existing TCP session we could try to OPEN a new TCP session to the same address:179 with the same security strings. We could use same or different BGP_ID.

<tp>
As per RFC4271, that sets up a second FSM and leads to connection collision and the shutdown of one system, the one being dependent on who initiated the stuck session, so it could fall to the stuck system to act, except it is stuck so it cannot.

I have not seen an analysis of exactly what has gone wrong but cannot help thinking that it could well be a bug, in TCP or BGP, in the peer in which case expecting rational behaviour of it might be expecting too much.

A different approach, leading on from this idea, would be to reserve another TCP port number for BGP use which BGP could use to check out whether or not it can establish a TCP connection with the peer.  If not, then the peer is beyond help.  (TCP ports are a scarce resource but then functioning BGP is rather important to the health of the Internet).  If it can establish a TCP connection, then there are plenty of options available.

Tom Petch

/* When we discussed eBGP peering between VRFs of the same PE it was confirmed that most if not all implementations (at that time) do not check for different BGP_ID when accepting an OPEN). */

If a new session succeeds and we sync routes we are good. Old session can be terminated. No data plane disruption at all.

If not it would be indeed a sign that peer's BGP is not doing that well and perhaps confirmation that in some deployment situations it would be good to remove him from the picture after draining his routes from our peers.

Best,
R.