Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

Enke Chen <enchen@paloaltonetworks.com> Fri, 23 April 2021 17:31 UTC

Return-Path: <enchen@paloaltonetworks.com>
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 926FD3A17E8 for <idr@ietfa.amsl.com>; Fri, 23 Apr 2021 10:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paloaltonetworks.com header.b=esTMpkVL; dkim=pass (2048-bit key) header.d=paloaltonetworks-com.20150623.gappssmtp.com header.b=s2kzz1D+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb10Kt2eRLUx for <idr@ietfa.amsl.com>; Fri, 23 Apr 2021 10:30:59 -0700 (PDT)
Received: from mx0b-00169c01.pphosted.com (mx0b-00169c01.pphosted.com [67.231.156.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7863A17E2 for <idr@ietf.org>; Fri, 23 Apr 2021 10:30:59 -0700 (PDT)
Received: from pps.filterd (m0048189.ppops.net [127.0.0.1]) by mx0b-00169c01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13NHToGL024207 for <idr@ietf.org>; Fri, 23 Apr 2021 10:30:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS12012017; bh=2aAAWwxOWYIRuHWfj5Q8uHjfyF4lAIaORFLvZuGELFo=; b=esTMpkVLmjntSQfyB6LjJgAeK2Gxrh+hZen5uM0Afz2WgBV4xjasFzxZa4qht++vfB54 eRgDk+X4ag0Tc61kpLC8DND/zuzOO695OagR7CCcVrgfUkGmLE8xWDsgpUKn1pWIjQ1i Rvb7KAZJVCdiGwAI1VHRdHyo2rBH4/wlM06+5A2NZ/K66fKXT6QBHy9rKORMx9mfBn9j UrQ+d0kbWjS+vtHKT3tPqSdnbkT8OcYNEhaseZb+tmjaGuKHAVOxhN/ECAP/+qj/zbQ9 uYH/JtUp1hj9+jOkn7JEna6Mfkwc9H4TH31FzFZACo0n/hqdbUHkggOkkDUdChw6BoAn mQ==
Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by mx0b-00169c01.pphosted.com with ESMTP id 383brperda-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <idr@ietf.org>; Fri, 23 Apr 2021 10:30:57 -0700
Received: by mail-lf1-f70.google.com with SMTP id q24-20020a0565122118b02901ae16b0713aso11877007lfr.16 for <idr@ietf.org>; Fri, 23 Apr 2021 10:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2aAAWwxOWYIRuHWfj5Q8uHjfyF4lAIaORFLvZuGELFo=; b=s2kzz1D+7CNJS3Mx3yJKV0EZ2trbRsMVT0uvxFMoWxNof/OrObNPAokp+knIQJwf3L APfaK6gLNZqpjMRNEkaDkxRGkf+SFCGegbwmvXUQgTCd/QvLJvtPETdovIN+Z6VXzVNU 3x+HeXSrAkpAZpyrrlouGW+5CbP9AdUPHm0ywQu5Z6IXbavSQrqPuFLLFzMdmMtMhBm6 AD6lTw6P9ezFzgceQekh4L+1zdZaV4VBXwxtnIFdUfdmbV4R2STpsxRGEPZ+HXkWeA4w hvWqzTeYfcZP3Na1yg+2lIhtV5UUr/dTcXlngWs1sbaFNh6YtHNYzCJP2e/V+cY/AgF1 EM8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2aAAWwxOWYIRuHWfj5Q8uHjfyF4lAIaORFLvZuGELFo=; b=I4dQK8sHswMXwcY65B3ADdlljZzAnskmiTf2TGTUZSrjBsQ7Ht1Ch+1XhFy6vIZdAl idlBW6s2Dedow0BrudpLMzRNqroVFRvpGzwI9V/uhZK9RTpX0hjLtDim7dq0gyz4SZIr bYhl/j/GEgNaDTp8pHu9/uZt4bzHU37qr6I2jGm8rlwC27dqPL2uXEXfh9K7nfZVQq3O tT9Ckhj4gkAHO7Y5pC9IZj5zCyexj4MhHZn+OSNjNbkUAp/14DG2O1oNQhHRxsVgspm1 kWDlO2Bn9zVgJTI1/N8+hhCHtnltci9wAmHx3Ik9sSxgneG/4upSHDkRysH8HHsG1D6B Q18g==
X-Gm-Message-State: AOAM530UiedScIYIyTNfpbMV4feo5H82irr1si191o9FaOoFaLYN88mC Au7n0LjAIwtWI77WRcoDGr5wfMUZVkhx1bpLKoSnsjSNkTwDc/iuXPon3UFTBGtU2+6x38dNyGf +3yiNFUlWFSEO+c5jX0s=
X-Received: by 2002:ac2:4216:: with SMTP id y22mr3539436lfh.422.1619199055954; Fri, 23 Apr 2021 10:30:55 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJwv/eulBeFUJQFMaVUC7+88iRLtzoOoP8YSsm+wwnbU9eiKxwzH6RZoZv1rWMvWo64662stlZNOYVJsUUpn424=
X-Received: by 2002:ac2:4216:: with SMTP id y22mr3539421lfh.422.1619199055531; Fri, 23 Apr 2021 10:30:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAL=9YSVy+mvxvAv+maxkUSzPbe0bfnUy-XJJTtcVhi3S3bm=WQ@mail.gmail.com> <BYAPR11MB32074D8142CCE2C2B50B2C32C0459@BYAPR11MB3207.namprd11.prod.outlook.com> <YILA1sLuzMd47LYR@snel>
In-Reply-To: <YILA1sLuzMd47LYR@snel>
From: Enke Chen <enchen@paloaltonetworks.com>
Date: Fri, 23 Apr 2021 10:30:44 -0700
Message-ID: <CANJ8pZ8PTudSx9ie-eEHbPKEHDeTNJ1-C_u116NbWXh5d7kyMg@mail.gmail.com>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>, Ben Cox <ben=40benjojo.co.uk@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000086ab0305c0a728cb"
X-Proofpoint-ORIG-GUID: aEeza6UuLFgwOzBa58ywm9ZM_V-hutI1
X-Proofpoint-GUID: aEeza6UuLFgwOzBa58ywm9ZM_V-hutI1
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-23_07:2021-04-23, 2021-04-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 priorityscore=1501 malwarescore=0 phishscore=0 adultscore=0 impostorscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104230113
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FfWIPsx-EzH4-rKLwx_QkCPFEOI>
Subject: Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Apr 2021 17:31:05 -0000

Hi, Folks:

The holdtimer already conveys whether the session should be timed out
sooner or later. It makes sense to tie the new timer with it, perhaps with
a configurable multiplier. The default could be 1, or 2.

Thanks.   -- Enke

On Fri, Apr 23, 2021 at 5:43 AM Job Snijders <job=
40fastly.com@dmarc.ietf.org> wrote:

> Hi Jakob, group,
>
> Thanks for the feedback, a -02 has been submitted.
>
> On Fri, Apr 23, 2021 at 12:56:40AM +0000, Jakob Heitz (jheitz) wrote:
> > I propose to add this text:
> >
> > It is possible that a BGP speaker presents a TCP zero receive window
> > after receiving a large batch of updates. Resetting the session to
> > such a speaker may just repeat the large batch, whereas waiting a little
> > longer may have given it a chance to recover. The possibility of this
> > occurrence makes it difficult to determine a good value for the
> > timer. The default value of the timer is therefore recommended
> > to be 15 minutes.
>
> In this email John Scudder appears to suggest using a separate new
> timer, and populate the timer with the default HoldTimer value (and the
> -02 draft attempts to describe exactly that).
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_idr_E5pqxIObPS7e9A2IqIApTHVSfig_&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=ic9GqvTL_AVNp--whyEU4xnDPEpswdHPBNt_XoBG99g&e=
>
> you propose 15 minutes; so it seems there is some convergent thinking in
> the group the proposed timers at hand is in the order of 'multiple
> minutes'.
>
> How long should a BGP speaker be willing to buffer on behalf of another
> BGP speaker's inability to progress message processing?
>
> If the oldest message in the queue is a KEEPALIVE message, and its been
> stuck there for more than HoldTimer, wouldn't we have expected the
> remote side to have killed the BGP session anyway?
>
> Would you mind sharing your thinking on why a default of 15 minutes is
> better than for example 180 seconds? What do others think?
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=PHKZKmQoCjqpWGGBhDIpOnAaSlDjeRsLdEPlOwChzyw&e=
>