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

[Jeff Tantsura <[e-mail]>]

Yes, support 

Cheers,
Jeff

> On Mar 6, 2023, at 12:53, 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