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

Robert,

I'm not sure Bidirectional Forwarding Detection and BGP hold timers
are solving the same problems here.

On a lot of platforms the BGP hold timer is managed by a control
plane, while it's not uncommon for the BFD session (if enabled) is
managed by a separate data plane. I am under the impression that there
are a sizable amount of deployments and peerings not running BFD, with
either eBGP sessions (I don't know people doing BFD with IXP Route
servers for example) or iBGP sessions (where there are arguments about
best practice on if BFD is a good or bad thing to enable inside the
core)

The core part here is that BGP's own keepalive mechanism has a
documented flaw that needs to be fixed as it's suspected to be the
cause of a handful of issues in the wild.

BFD would also not solve one of the issues this internet draft is
targeting (one way congestion of a tcp queue of a signalling
protocol). It's easy to imagine a situation where BFD keeps being
exchanged, but due to some other fault BGP messages stop being read.

This internet draft is designed to try and target those faults, and is
not targeting rapid detection of link breaks.

Does that help clear up our intentions?
Ben Cartwright-Cox

On Sat, Jul 30, 2022 at 11:17 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Job,
>
> In my books we should really discourage people from using BGP keepalives and move them over to BFD protocol to determine liveness of BGP sessions.
>
> While this draft perhaps does improve RFC4271 I am not sure if we are moving in the right direction.
>
> The draft does not even mention BFD once which is disappointing.
>
> Kind regards,
> Robert
>
>
>
> On Sat, Jul 30, 2022 at 7:23 PM Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
>>
>> Dear IDR,
>>
>> I’d like to bring this draft to the working group for another round of consideration for WG adoption.
>>
>> There now are two implementations which have implemented the concept (OpenBGPd and FRR) in releases shipping to customers.
>>
>> Our hope is that more BGP implementers take an interest to help improve global Internet routing system stability.
>>
>> We welcome interested parties to help co-author the document, specifically in these areas:
>>
>> - is the 4271 surgery correct?
>>
>> - graceful restart considerations?
>>
>> - do chassis/COTS router vendors feel comfortable with the suggested timers, or is more leeway needed?
>>
>> The goal is to bring the fault stale state back from days/weeks to a few minutes (not to race to the bottom and seek sub-minute resolution).
>>
>> We’d like to ask the IDR chairs to consider kicking off the WG adoption process.
>>
>> Kind regards,
>>
>> Job
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Sat, 30 Jul 2022 at 13:06
>> Subject: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> To: Ben Cartwright-Cox <ben@benjojo.co.uk>, Job Snijders <job@fastly.com>
>>
>>
>>
>> A new version of I-D, draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> has been successfully submitted by Ben Cartwright-Cox and posted to the
>> IETF repository.
>>
>> Name:           draft-spaghetti-idr-bgp-sendholdtimer
>> Revision:       05
>> Title:          Border Gateway Protocol 4 (BGP-4) Send Hold Timer
>> Document date:  2022-07-30
>> Group:          Individual Submission
>> Pages:          7
>> URL:            https://www.ietf.org/archive/id/draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> Status:         https://datatracker.ietf.org/doc/draft-spaghetti-idr-bgp-sendholdtimer/
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-spaghetti-idr-bgp-sendholdtimer
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-spaghetti-idr-bgp-sendholdtimer-05
>>
>> Abstract:
>>    This document defines the SendHoldTimer session attribute for the
>>    Border Gateway Protocol (BGP) Finite State Machine (FSM).
>>    Implementation of a SendHoldTimer should help overcome situations
>>    where BGP sessions are not terminated after it has become detectable
>>    for the local system that the remote system is not processing BGP
>>    messages.  For robustness, this document specifies that the local
>>    system should close BGP connections and not solely rely on the remote
>>    system for session tear down when BGP timers have expired.  This
>>    document updates RFC4271.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr