Re: [Idr] WG LC for draft-ietf-idr-bgp-sendholdtimer-03 (3/23 to 4/12/2024) - Extended to 4/19/2024

[heasley <[e-mail]>]

On Fri, Apr 12, 2024 at 11:17 AM Susan Hares <[e-mail]> wrote:
> Greetings:
>
> A great deal of good discussion has occurred regarding
> draft-ietf-idr-bgp-sendholdtimer during the WG LC.
>
> However, we need additional comments on this draft prior to completing the
> WG LC.  To enable this discussion, I an extending the WG LC an extra week
> to 4/19/2024.

I support adoption of this draft.  The problem exists, has occurred in the
wild, and can be demonstrated with ease and has been.

I have not really followed the adoption discussion, but the contention
seems to be with the draft-chen-idr-tcp-user-timeout solution.  It is Enke,
so I am probably missing something, but I do not believe that it correctly
identifies the problem and is not a solution to this "bgp zombies" problem.
Specifically, rfc5482 reads
  "..."user timeout" parameter that
   specifies the maximum amount of time that transmitted data may remain
   unacknowledged before TCP will forcefully close the corresponding
   connection.",
this does not match the problem correctly, as I interpret that description.
TCP Acks are received for data that has been sent, after which no further
data can be sent and therefore there are no further acks to be received.
rfc793 does not appear to be different, nor are the updates in 5482.

Even if I have misinterpretted the description, it does not seem to be
clear enough to expect that it will have been implemented consistently,
imo.

I do believe that USER_TIMEOUT could be used for other failures, but it is
not clear to me that it is any different from BGP KAs.

Regardless, the two drafts are not mutually exclusive.