IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Fri, 19 April 2024 13:16 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB0C14CE52 for <idr@ietfa.amsl.com>; Fri, 19 Apr 2024 06:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVn_aXzGjJvF for <idr@ietfa.amsl.com>; Fri, 19 Apr 2024 06:16:12 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E63C151097 for <idr@ietf.org>; Fri, 19 Apr 2024 06:15:34 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a55692e09c9so114046766b.0 for <idr@ietf.org>; Fri, 19 Apr 2024 06:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1713532532; x=1714137332; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WreFxyxKzMDXEW3KP1l1jJHqdHQit6/cIZpqENvq6Cg=; b=cLJK5vdB3zwblvlkteuHdSwGkZqpJpzA1fPm1TKaRWrQ4y4s/as0yFtTr277NKkbNV ppan7eLdiqYQ87t1ELef1QgPycXcYSWSmJHsE1PnYNuvxOvjl1j+azV5RtW+KTyi1Kic H9QLnuuX2KId+UrGqmIZefOWWPxVUCVP+UZGTZPxpxRwfqA0CePAUURWxBzHyTeC8V65 kHy20xrcY0RE6sGbuDGij2adp2sD8gbpVXYLCCcYsURoIUJmUdpNGGrKDAYScCo85ask lZ15dTJYod7COtuG8BMwlUJzhZ+0aNJz0M2SbmAj8IWPqMGEcTIUUY5yB69TC+PfxouE jnww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713532532; x=1714137332; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WreFxyxKzMDXEW3KP1l1jJHqdHQit6/cIZpqENvq6Cg=; b=NzpfWsWBDq1A8RFuRJ29Ry118cAMiVv4S0MDD3x6EN9/r8N3OnPBiL0kYiYF7TnWqz GOIRkVwR87vq0GuarJBDsW7KCyQufwjk2+i42+WUJw/n63pci1fXkELr3+JCBa+CxYZq CTCPtmFdkfhMpCsJr5UT2Q5rWFcIu1GecgNyIzBZRFk0K8zIA9fAseBDRd0bf2BN8lbN M2OlXOlFgT6eae6N1oZeZmQ8O9HTW58dxs4WZfCrSJ39v+yWBDuDb3Ykp19f6xAJO6EU 6kTLo56s041PfV5OW9a0lTGuF5xGPLulIVkDRH88F12P0ZAmzmXeMxzSTaaXVI3i+YUi PaWA==
X-Forwarded-Encrypted: i=1; AJvYcCWaDQMPPeHpN0ADJfvf1XyIsazisIpKn8oINSkQi7EzJZE3iId9Q4fyBLMecB5XzgwzWzCurCXzUCjdHcg=
X-Gm-Message-State: AOJu0YzVo2d/onmQl2cqk8KRB2ltm71qZDaQPX2N2XSN3b0A5+GCb8OY RVrWkm21+CQ+aYfMunNCiztFtMooMWsaZNHdA6jsNGZdFAQlX78I4TfQ9Uh0gKDA2gSNG9ZmQ75 4r7HTGexKpd7/6qeUAvrg/FjCcGekSBDUe7kmIS9M+1iebsQ3Thc=
X-Google-Smtp-Source: AGHT+IESiuKwyMHDvTbF3ubNreyiyJ2a8DDe7ccgRNkYVyNK1ntpRW4fhGtENqW4MHt9jat6GfMPsbbE4jXKUXn7RaE=
X-Received: by 2002:a50:a416:0:b0:56e:a76:b79a with SMTP id u22-20020a50a416000000b0056e0a76b79amr2087821edb.7.1713532532141; Fri, 19 Apr 2024 06:15:32 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR08MB48573863C5259A0DF98C335CB3042@DM6PR08MB4857.namprd08.prod.outlook.com> <CABNhwV073u1SGPW6scLAHdsTHpy8qsKdqguYo6KpS5rbhjjpDQ@mail.gmail.com> <ZiHrY8ww0CULyLvZ@shrubbery.net>
In-Reply-To: <ZiHrY8ww0CULyLvZ@shrubbery.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 19 Apr 2024 15:15:21 +0200
Message-ID: <CAOj+MMEwXJS6xbKfk69FARv_pCjx9u7Xg_c1TgCOyzuf81e1jw@mail.gmail.com>
To: heasley <heas@shrubbery.net>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3cdaf061672e171"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FrTeHYqq1-t3mt3g8MfZCIXZezQ>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-sendholdtimer-03 (3/23 to 4/12/2024) - Extended to 4/19/2024
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2024 13:16:16 -0000

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

If previous data sent by TCP is ACKed what would stop TCP to send more data
? Note that we are obviously talking about case where there is data in the
sendbuffer.

Thx,
R.





On Fri, Apr 19, 2024 at 5:56 AM heasley <heas@shrubbery.net> wrote:

> On Fri, Apr 12, 2024 at 11:17 AM Susan Hares <shares@ndzh.com> 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.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email