Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

Keyur Patel <keyur@arrcus.com> Wed, 16 December 2020 00:55 UTC

Return-Path: <keyur@arrcus.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 525A33A0A08 for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 16:55:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
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 ZrDYefOQugnS for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 16:55:11 -0800 (PST)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2053.outbound.protection.outlook.com [40.107.92.53]) (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 C9C153A0A0B for <idr@ietf.org>; Tue, 15 Dec 2020 16:55:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RQ9UAnIAlXlaaeCrTBIV7au9jR+cSJX1D3I56RsYXKuVKDxfff6d1Q7gn/5WrXiQk0Wy2lQGfCkM8Dr1oRldFrcZFPVTAjGbFvC54c+/NtrEow+kv9lg0OrsanyfFsJTxPy7mzMJPH3O4g6Oy0dAXuIX6kzZCFe19TNE7pDgBfbs+x9tpBI4MnuRSyjgxgMjVueFq7+e1TcMBqQYMnwfYqj67At/mhf/XNwyI1sq9Gjqw/DoktwLkLq01duwMYXxnSKIPp/ab8dpBusEMFRUlkgXCIdnOVo570SFyiwjFWWrj6rAttRu+JJmrq94CAKh9SA//1TD/L9rHfAwgCXgFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jQJBKuShYmU3hjBYSudP3JxGmTqdtmjAjFzJZMu3mlE=; b=KD15UdDUkWJ+/SXpN+bQwkcEEoFOQuYBxnbZDa/MsZoKH/CM6d+hLZW3nAQ0ocL7bUTY3MPAtiOWp7D0umu2tJ2K42mclzSO3bZ5t9ml3prwnLqHKB2aONjtoicSxGFGOeADNH9281IXqpnRkpmVbkF/k80Q/9jaCgdkd8QNGqyaTV7ZaBDSrwSS92ZUNKY0qos5W18RWeI4TiBy70pfEw+1vMx2Tb3qBYAY7oAQr305XGZedIxsiRjlsAuHzSDB579RDtcNaep4SuSpHtLlH9VCosmxwmaEXH5ubE37apnMqmjr5YfSpWnclm0pwGIr8J4K3GjPWScZ6qAalSRHwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jQJBKuShYmU3hjBYSudP3JxGmTqdtmjAjFzJZMu3mlE=; b=hxHBERiTWAj70ET42iN6qNVmO339aa1OI6uErZm6F2GkQ7zxlHPWa5Dy6YNY6tnL9y7/D7Sz73WyOUNwJFwipu/vbyRAlYXIpYT1mNfU6w+LS1389+qz4t9rw3lWwR+h79Z2ohBMAtKKbKoOX4gDv+dUrQe0DcMo//PzqQuQx7Y=
Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by SJ0PR18MB3818.namprd18.prod.outlook.com (2603:10b6:a03:2ca::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 16 Dec 2020 00:55:07 +0000
Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4%4]) with mapi id 15.20.3654.025; Wed, 16 Dec 2020 00:55:07 +0000
From: Keyur Patel <keyur@arrcus.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Job Snijders <job@sobornost.net>
CC: Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
Thread-Index: AQHWz/PTKqeqTOTeJ0S3IgM5E+6+BanzMNSAgABM7oCAAAJ3gIAABHgAgAUVKwCAABAegIAAD7aAgAARSgD//5szgA==
Date: Wed, 16 Dec 2020 00:55:07 +0000
Message-ID: <D94B0E87-30F7-409A-BCCF-D924F652151A@arrcus.com>
References: <X9PHRuGndvsFzQrG@bench.sobornost.net> <CAOj+MME4OHmoqJfzNQ4Tj6+wCd1kJVHPfJsDbk_+Xh8fh5G8Dg@mail.gmail.com> <6F7C5906-51A8-43C2-8AEC-3DB74CB9941F@tix.at> <1B4E7C9D-BBFE-4865-87F9-133ACE55D122@cisco.com> <22C381D0-2174-4828-A724-FD97B2FE0BCB@tix.at> <9D6268BD-C555-4B9A-A883-9B55EEB5D5DA@juniper.net> <91D9B9F7-0DBE-45E6-84D5-2E3D9F8C44A1@tix.at> <X9kweQ5EtTL7tOAM@bench.sobornost.net> <B6F84ED2-E673-4798-AF89-DFC25EC2CCBA@juniper.net>
In-Reply-To: <B6F84ED2-E673-4798-AF89-DFC25EC2CCBA@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=arrcus.com;
x-originating-ip: [2601:646:9a00:1990:9050:6175:d6b1:be6f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2870aa82-62df-4e2b-7c6c-08d8a15d3bbc
x-ms-traffictypediagnostic: SJ0PR18MB3818:
x-microsoft-antispam-prvs: <SJ0PR18MB38183D536D5257B050AE5495C1C50@SJ0PR18MB3818.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 91FgjLd+j79ApJPNGOzOcWJhIfE0+/zMNDwlI6/tW0CT2fNqJybQ0xWgfE73ukr+WAv73EOt7tbAKhnwT7NAWvL/QjZxYPZbopM4ZGWXaXTjV/+m6+xC9BF9jlAfJgXsQlTB2rCDFTvSo7rFghx0uW6bWwCEghRDLpCJ+7KgwSwvWhE5WXNhcDJM9gYLw++TmwsOTzC0oAntCNRMHpRjqKNWFo79FqHp/HAS2HCWhWLJz8Wbq/rflcvK1wtmNEugzX5yWap9ADsuRblkNDmTrOseL5DKV9GLv9NPU8JP4pnlqE+Ym3GyqkWuF3yWhbMAcpZU9h6iRLdXbB+Yg6T2Yfcssx3CjruC6bNA/33Lm0SMo9YdjOkaVaBlGZrlIPvT0qSX8IQ6JTokdfkDxYBQTtkpIK146Jm5ereaPJ/QbYsahur075LMZjQU9NFX0a7VlGvDshxhwZa8AhRSB3oxtA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(39830400003)(396003)(136003)(8936002)(5660300002)(4326008)(110136005)(66556008)(71200400001)(2906002)(966005)(6506007)(478600001)(76116006)(66446008)(33656002)(316002)(6486002)(83380400001)(86362001)(36756003)(186003)(66946007)(64756008)(54906003)(2616005)(8676002)(66476007)(6512007)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?OVRmZTIrQ3BYSTB5bi9zbElxZUpsMTkxZlM1L1puMlo4WThjQ0NxQkZ4T3ZE?= =?utf-8?B?RmJDVjhNY1VKaFpTZ1dFTS9ETXdIMTVDR2NGNVFieVNTRFVZL3NuSnZNd2N6?= =?utf-8?B?elZkQjJzMlg1dllRaUxscUxncCt1bGpheVBOdDdpeDR2ME95MmROVlBKQXZM?= =?utf-8?B?b3NDOFpySHg4bjJaclJtNGMra2o4ZCtWdDI3U0RhdUpyWGtJbE5hd2QrK3dh?= =?utf-8?B?YzVUZEZBazdJQ0xXM3RsVkZscjNrMWR6c2xLYUJtU3AzeUNUYUVOMFRoK1JO?= =?utf-8?B?YWx3WkRjSWxNU0hjL1B4dm9oVkprWFhiS0dlL0V5U3Q5ajB5RVpVS3pxdzFh?= =?utf-8?B?ZFJnOWN2U0plemRMNXRhR2F0QlhaN1hzekUrcEhTamd0ZmJtRzIrajhtclVl?= =?utf-8?B?bVc1L1hna0lac2FERitQMG1GZFBPMEJoOGJrMm1pZXZCZFZ2aHEzQVNaUFhr?= =?utf-8?B?eU5rOU1hZnlPbzNiZldXVVUyRzNyYnFqVElNRUhIc05UeFBrTFlaSkladzhK?= =?utf-8?B?K1JYMGRSVTFxTGdaYzY1N3lNWiszUlY3STBNRTVrVWhLSm1KckdKN1dMSmxJ?= =?utf-8?B?VEYrTlQzZk1acHJqRi9tZStHYTQ0VDFpMGp1ak4vSkZETU44SUtBUjVyQlRm?= =?utf-8?B?TFJMaVp1VENPeFlJcCtuVXFJMzlhZ3Y3K1ZVbGtmRytZN29KMVp2N0l4L2tx?= =?utf-8?B?b3VWQi81RzJpNkUwTElwaWh3Szh1SE5XclYxazlRdmxILy9SOEVXOEdHY3NO?= =?utf-8?B?K21ZWWNyQkI0WXNVdWk1ckZwL0RSSnk0aVJNeUtHbGMzaGZ5N3FoSlYySld1?= =?utf-8?B?ZmlvM2p4MUJMeVY5WGdxYnlsWmZINmVoOWhjaFo2a2E5SmdVRU44Ly9RWGU1?= =?utf-8?B?eWh2Y1VMVEZaRUxaRnN4VTRIVTQvdHc1VWxPTnVkV0RYTm90eEY2K25KMk13?= =?utf-8?B?MEZuTGdSK2RNRWI0RW9JS0tiVmpKVTJ1VHJ6YWFZWGlpWmoyK2NobWZyQnY5?= =?utf-8?B?alB3YjVrUk5JSUxCUVJuUlhaWUZJWDR4bCtQOWVSdVB3cGFCL2pOQ0NoQXpq?= =?utf-8?B?VU9qaWNSSnVxSEZCNk1udm9KS0dNSHU1VkloZGdLNmVRdDN3S3N5Z3dkTUhy?= =?utf-8?B?Y0gzdHJZZUlXVnk1L2trUlIyZ2hyR1ZBellDRU9tOVN6ZWprdUVXSGdkazgv?= =?utf-8?B?b1JzTHBzamkvNHpvc0N4bzdQdkxhQnRxS05wdmpITUFwUWNQNnZCRkthTUVU?= =?utf-8?B?cUpSYmVZSm01WjlvdmNpaERaaEdTZlBYZEFqaWxwZG8xdGVFZFd4YTlicmNk?= =?utf-8?B?L0pZS1hTQ3JZbnR5TWlReFB3U0xwUXFiSWd1RjU2clJFVHBLY2VrMzMwbEc5?= =?utf-8?B?dzNkZHdScEJYcGhxODdzYlk3M3p1Z29tN254bisvRU9wR0xXeXFqMytGb3Rv?= =?utf-8?Q?gI2b5Xwy?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <704CEC9448224C48B83034DE1A877387@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2870aa82-62df-4e2b-7c6c-08d8a15d3bbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 00:55:07.7934 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6F7Xc9BPW4TM/eUYXEMeKM01GGjoqm+CbKl1inWFU7Cd0nCkWE30DKR53TdVcQY12IBsDmOmd8ZW1DxHNMYXkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB3818
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/N6h4oi1Gc2pyS5M8f14TTbx83bc>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
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: Wed, 16 Dec 2020 00:55:12 -0000

My comments #Keyur

On 12/15/20, 2:56 PM, "Idr on behalf of John Scudder" <idr-bounces@ietf.org on behalf of jgs=40juniper.net@dmarc.ietf.org> wrote:

    It came up earlier in the discussion that HOLDTIME serves at least two different purposes: neighbor liveness detection, and as a metric of BGP protocol health. If the proposal is adopted, the former use is potentially problematic in deployments where the hold time gets cranked down to a very small number.

#Keyur: Yep and it has been cranked down to a very small number in number of networks.

[*] Of course, you can argue that this is a bad use of the BGP hold time, and that the operator should use BFD instead, but sometimes this isn’t done, for whatever reason. 

    Because of this sad state of affairs, it seems to me that if we adopt this proposal, there should be a new hold time introduced, call it TX_HOLDTIME if you like. It could have the same default value as HOLDTIME, but (and this is the important bit) would not inherit any non-default value of HOLDTIME, it would have to be explicitly changed separately.

#Keyur: The TX_HOLDTIME would need be negotiated with a higher value (lower negotiated value can result in sending speaker somewhat abusing the receiver speaker) being chosen. __ 

Even if you have a new value (negotiated), it isn’t going to always solve Job's problem at hand. __ Assuming receiver is stuck it is not guaranteed that receiver would reset the session (sender would have to do it anyways). Then why not have a sender implement a knob that essentially says the same: Reset a session if a sending speaker cant write for more than configured interval of time (or 3*Holdtime or Holdtime interval).

Regards,
Keyur

    —John

    [*] I assume this is obvious; I’m prepared to detail why if people don’t agree.
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr