Re: [Idr] New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

> On Aug 3, 2022, at 7:50 PM, UTTARO, JAMES <ju1738@att.com> wrote:
> 
> The decision whether to retain forwarding state in the face of a control plane failure is dependent of the AFI/SAFI in question. For those that are internal to my network i.e Kompella VPLS/VPWS a catastrophic loss of the RR topology should not invalidate forwarding if NH viability remains. Long-lived-gr clearly calls out the reasoning for not nuking the data plane. IMO the decision needs to be made on an service basis where different operators may have varying tolerance of "incorrectness" for different AFI/SAFI(s).  The majority of customers remaining viable with some incorrectness is preferred over tearing everything down. 

Perhaps little surprise, Jim, you were one of the people that came to mind when I wrote my text below. :-)

Graceful restart (and it's long-lived cousin) don't dwell very much on the details of what sorts of incorrectness may be piling up behind the session being gone - only the hope that it's not too bad.  LLGR at least signals that it's stopped pretending everything is completely fine and gives the downstream routers enough choice to de-prefer those stale paths.

When you simply lose a session due to a TCP hiccup, it's probably not a problem.  When the control plane crashes suddenly, it's a problem, but you at least have faith that it'll come back at some point.

When the sendholdtimer mechanism kicks in, it's because you have 4 minutes (or whatever our magic constant is) of stuff which may include Update messages that hasn't gotten through, so you're already acting later than the above circumstances.  That detail, and its consequences, needs to be documented so that operators can make appropriate GR retention choices.

-- Jeff

> 
> Thanks,
> 	Jim Uttaro
> 
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Wednesday, August 3, 2022 2:54 PM
> To: Donatas Abraitis <donatas.abraitis@gmail.com>
> Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>; idr@ietf. org <idr@ietf.org>
> Subject: Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt
> 
> Donatas,
> 
> On Wed, Aug 03, 2022 at 09:19:02PM +0300, Donatas Abraitis wrote:
>> A couple of words regarding GR too (might be added):
>> 
>> "[RFC8538] defines an extension to BGP Graceful Restart that permits 
>> the Graceful Restart procedures to be performed when the BGP speaker 
>> receives a NOTIFICATION message or the Hold Time expires.
>> This document appends BGP Graceful Restart procedures to be performed 
>> also when Send Hold Time expires."
> 
> That's a good start for the side dropping the session due to the sendholdtimer expiring.
> 
> The authors will want to consider what the operational considerations are for the other side of that connection.  There's no way to tell in the face of a closed TCP session without related BGP signaling why the session went down.  If graceful restart is configured, the peer that was (probably) having problems will start retaining routes and the upstream already knew it was out of sync.
> 
> Jim Uttaro's point in the prior thread was, effectively, how bad are things?
> Are you better off retaining a lot of likely good state with some pending bad state?  Or, is BGP being used in a situation where graceful restart is simply inappropriate.
> 
> While this probably seems obvious, this draft motivates the question about dropping the session because Stuff Isn't Getting Through.  This bit of obvious discussion needs to be in the draft.
> 
> -- Jeff
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!jwmz-E-6Cd5M8DTgSBfS9MOgqZxUdyb4xRQfd6V_yDDb2FtQ9vbtvpt369JzsHi_Ef6mJ_k$ 