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

[Robert Raszuk <[e-mail]>]

Jeff.

If you are saying that RFC7130 is not yet widely available, this is not the
convincing factor here.

But nevertheless if you are building high speed DC fabric and blackholing
traffic upon last LAG member failure up to holdtime then this is IMO
suboptimal design (to put it very mildly :).

To the other point brought before for IBGP and IXP scenario failure of your
sessions to RR or RS may not mean that the data path is bad. Some folks
proposed BGP persistent ideas to keep it for hours if not days - but this
is a different aspect.

*Anyhow .. back to the draft:*

Is peer sending Receive_Window of 0 really a good trigger to bring the
session down ?

Is BGP now expected to deal with (how) reception of Window zero from any
peer at the TCP level ?

Even if so why no reception of BGP keepalives will not bring the sessions
down on the other side ? I guess this is an indication of remote side going
foo yet it still sends us keepalives.

Why do not we modify RFC4271 to only allow sending keepalives when the
remote system is indicating its liveness by sending his keepalives ? That
seems to me as much more proper behaviour then new timer.

More ...

If the RCV window is 0 how can TCP send anything to the peer including TCP
RST ?

If the peer is saturated, how good is it to assign a new IANA
error notification code if it can not be sent to the peer ?

Section 2 provides the most interesting comment out of the entire draft.
Yet authors want it removed before publication .. why ???

Last - the article https://labs.ripe.net/author/romain_fontugne/bgp-zombies/
does not make a clear conclusion of the nature of stuck routes. so I am not
sure if this is also the right reference for the draft.

Best,
R.


On Sun, Jul 31, 2022 at 1:45 AM Jeff Tantsura <[e-mail]>
wrote:

> Job/Ben,
>
> I support advancement of the draft, perhaps clarifications wrt BFD  would
> be in place.
>
> Robert - BGP at TCP level and BFD are mostly orthogonal and don’t share
> same path/achieve same goals.
> In many DC BGP networks, LAG is a primary connectivity model (more
> configuration than an actual connectivity artifact). Running BFD over LAG
> has a number of serious implications and is not supported by most open
> source implications.
>
> Cheers,
> Jeff
>
> On Jul 30, 2022, at 15:50, Robert Raszuk <[e-mail]> wrote:
>
> 
> 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 <[e-mail]> 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 <[e-mail]> 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=
>> [e-mail]> 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: <[e-mail]>
>> >> Date: Sat, 30 Jul 2022 at 13:06
>> >> Subject: New Version Notification for
>> draft-spaghetti-idr-bgp-sendholdtimer-05.txt
>> >> To: Ben Cartwright-Cox <[e-mail]>, Job Snijders <
>> [e-mail]>
>> >>
>> >>
>> >>
>> >> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/idr
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>