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

Hi Ben,

Indeed as I mentioned this draft fixes some of the original RFC4271 gaps.

But I am still not sure if this is the right way to fix those gaps in 2022.

For IXPs I am not sure if reacting fast on any BGP issue to RS is really a
good thing. BFD could be used there peer to peer with RS assistance. See:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rs-bfd-07

For iBGP sure you would need multihop BFD with all of its pros and cons.

So I am not against this proposal to move fwd ... as long as it actually
discusses BFD alternatives to accomplish the same**.

**And sure as BFD it is tied to BGP - so the protocol in the event of
noticing malfunction should signal locally to the data plane to bring down
the session. Some vendors assure this is already happening, some are silent
... but bad implementations should not be an excuse for more workarounds
(at least for those who want to bring such sessions down fast - which btw
for IBGP may or may not be a good thing).

Many thx,
R.

On Sun, Jul 31, 2022 at 12:38 AM Ben Cox <ben@benjojo.co.uk> wrote:

> 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
>