Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Robert Raszuk <[e-mail]>]

Job,

> The above changeset has been tested against exploit code we developed,
> it works.

My main issue with what is proposed here is that it completely ignores TCP
keepalives.

When I was exploring this topic with Enke we actually found a good number
of completely legal and valid cases where TCP will suppress flow
unidirectionally for a good and valid reasons.

When application (here BGP) is trying to be smarter then transport it is
relaying on we are looking at zoo of new hard to debug issues.

Of course one may say ... Oh if I configure long enough timers we will be
fine - and that is maybe true - maybe SendHoldTimer will be just an extra
fuse.

Currently draft says:

A HoldTimer value of 4 minutes is suggested.
A SendHoldTimer value of 8 minutes is suggested.

But I am sure there is going to be CLI to override it.

And when I see HoldTimer recommendation of 4 minutes ... well many folks
are asking vendors to support HoldTimer of 30 sec as they do not (or can
not) use BFD. What are they suppose to do ? Naturally will set
SendHoldTimer to 60 sec and the fun will start.

Regards,
Robert









On Mon, Mar 6, 2023 at 9:53 PM Job Snijders <job=[e-mail]>
wrote:

> On Mon, Mar 06, 2023 at 11:53:11AM -0800, Randy Bush wrote:
> > > But technically what is in this draft and apparently prototyped in
> > > one open source implementation has a very limited (read narrow)
> > > applicability.
>
> Worth pointing out: two widely used open-source implementations and one
> closed-source implementation already exist. All three interopable and
> independently authored, see Appendix A of the draft.
>
> > adding complexity and significan new code to bgp when, as you and enke
> > point out, the vendors can merely flush out their tcp implementation
> > where the solution is already specified.
>
> 'adding complexity' is a highly subjective assessment.
>
> The changeset to introduce sendholdtimer in OpenBGPD's FSM is very
> readable and concise:
> https://marc.info/?l=openbsd-tech&m=160820754925261&w=2
> The above changeset has been tested against exploit code we developed,
> it works.
>
> On the other hand, the solution Raszuk and Enke advocate was broken from
> the 90s until Linux Kernel 5.11 arrived, requiring a bugfix [1] that
> seems of similar 'complexity' as the OpenBGPD approach.
>
> So yes, new code somewhere in the stack will need to be added to deal
> with broken remote peers that are stuck in this particular problematic
> state.
>
> Using a recently fixed Linux-specific feature certainly is one way of
> doing it, but certainly not the only way.
>
> Kind regards,
>
> Job
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>