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

Hi Jim,

That was my point. And here comes the crux of the issue.

If all AFI/SAFIs run on the same TCP session than we have a bit of hard
time to have a "global" behaviour different in respect to retaining some
routes but not the others.

That's the price we pay when BGP is used for much more then IPv4 and IPv6
reachability without proper separation.

Some will say - oh well use multi-sessions with per session long-lived GR
setting - well we do know how successful multi sessions feature has been
implemented and widely deployed.

Many thx,
R.

On Thu, Aug 4, 2022 at 1:50 AM 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.
>
> 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$
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>