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

John Scudder <jgs@juniper.net> Tue, 15 December 2020 20:00 UTC

Return-Path: <jgs@juniper.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 521443A1759 for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 12:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=r1MJe7WA; dkim=pass (1024-bit key) header.d=juniper.net header.b=Dvvna4XR
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 pGPuU-XbcUyQ for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 12:00:11 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 4389F3A1731 for <idr@ietf.org>; Tue, 15 Dec 2020 12:00:10 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BFJxkAw023683; Tue, 15 Dec 2020 12:00:08 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Lg0KfQ9AKe0sBqi4ljY44VMgOCyX/Pm0x/oSxNF88DM=; b=r1MJe7WAkA4NoSre5JXpmIXlm2/y/1XWSmnmckt5wkWAX4dMpECwflPDV6PyFWeyIS5z A7q7QQxiAgEx1w+nh5e+GUG88p87f+xTPyWoOEdHjeO/0sPz5MMs0ujSlgAn9TmbBEWy QZCInyUNfdQoRGiQH2fP+nG7y6tnmKjBRRaVeXPQuMcIttK9tImNsWJFC7eCPIhtzZIg X1oug1+8yCMLHjrV2ANwSeFcZU3tvExLzTsBsbAeokFi/krL+4v1+5O8k5kyvE6qdmvr pCXarLpQDANEc8qp0LX6Xm0KTXpBUREkUqK+Cq071pMC1oG2HUvMcmCTMVJhaLRE3ywc jw==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by mx0b-00273201.pphosted.com with ESMTP id 35eygk0p5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2020 12:00:08 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Krj5gRz/thQi/eMY1YDQaZsVra5xAg89MoYhbJp5R0YT5rxKQ1ZtuApEH4/YD7GuE1hIxkUjW9CH3SmCx1wMRx5O8BMablHr0CXC/ZXuYH68z10iPgtuS9JUKbV9jTRBLFGrRIywvX5pIHlKVIqD9lDU3+0ffipK5yoyUtMUODOTDnM8GeftQXuiqo2dZ2vxOrOTk1KfKqLZVEQaXJs0r6LSsogzrRTHFDTBnKsnvP4yrc2DfdEombXi6LTTm+TOimmjkko+k12yeyPMahQcJUFoYHR9x9RFk/fU1cLlhu1EGPcHKcG1yPWuhDhytlA1ZYvn8huXCAiOr0wPO1nwbw==
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=Lg0KfQ9AKe0sBqi4ljY44VMgOCyX/Pm0x/oSxNF88DM=; b=RV3qFa/SiPhu5oRtNxeuqAGA8/jkPQXLBESDI8kyseaUtkJlQpiiX9l7m1rTIGj7lezmpBlxxvKe39QICH+LyoY4gQJjNyLvDZcaDg0/jGJJMazLA1PlE77o7KYsraVMWr6VR2Yi0/f7MLNubtYeLY5oeyTYzDFBjDDJhsWQpSiAhubvxrGIBFAogZKrS1iG2in5YfADjs2jUxlswBGtrWvhkLCnOdpsOvUia2vXAK54RYa/1+lSNFXzcs/g8tLRMt4176hZWmtzXXzNoHES6r3BMMiXFy9JwWc1H3MkJFqtM+3ketcYE9yy7rWvJjz8VKc/o3tC5shePtiDuqugGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lg0KfQ9AKe0sBqi4ljY44VMgOCyX/Pm0x/oSxNF88DM=; b=Dvvna4XR/+mzHHQSo33/WClzyoKhcVM3/uSiCgqjEU+kq6LGmLzHptLc5C9tVi2pNnJLYT67Yu2+v0m9d4Rn/Bt7RprweUkzq4wF1vgwfuu111DY+zJ8hyJmy0q/nfZaPReQ1eU+8FDDnwdNNjr5RA8jFDKsje5GRHUZw+XGkak=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6670.namprd05.prod.outlook.com (2603:10b6:208:d5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.15; Tue, 15 Dec 2020 20:00:06 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318%5]) with mapi id 15.20.3676.018; Tue, 15 Dec 2020 20:00:06 +0000
From: John Scudder <jgs@juniper.net>
To: Christoph Loibl <c@tix.at>
CC: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr@ietf.org" <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
Thread-Index: AQHWz/PUVnNdU7dhTEany/fuPhqhnKnzMNSAgABM7oCAAAJ3gIAABHgAgAUVKwA=
Date: Tue, 15 Dec 2020 20:00:06 +0000
Message-ID: <9D6268BD-C555-4B9A-A883-9B55EEB5D5DA@juniper.net>
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>
In-Reply-To: <22C381D0-2174-4828-A724-FD97B2FE0BCB@tix.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
authentication-results: tix.at; dkim=none (message not signed) header.d=none;tix.at; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8e721375-64c9-4610-0955-08d8a13404e4
x-ms-traffictypediagnostic: MN2PR05MB6670:
x-microsoft-antispam-prvs: <MN2PR05MB66704DE6D92EBC2D156F2154AAC60@MN2PR05MB6670.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kb8wvV6CFnKV9Ywwn7R0XMQhspsq2gzBQf+UiGVyqQrkv9CsKuUSaWcB5WvKQMpeL17Trs4x3ODb5dZQxMxVodmhtVfOVYqZnkOVu+kaLeELgbhiHezrhZW0oilrLG4qhx5Y/TUpHf70TYNsKp73VfmZLq51bf3gqH8hXZ250x273uYqz/o6ikTl+nVW9+SPvXb79vY56vXliJLj9s/7xX9z6LWqi1nxrE7IGN2QIo+aml58oUmrHQiX+8vbnIr4PwrvCKmHb6kv1ttL5FqO6M5YcrWmJux5RM9C+vVh/Y2FJuixAtKGhYbVwC9CXCIMJWq7kV3J08o1D4atpEoIsd0DxKwPiK6P1TiMTz3OQ49+CS4XvS+rkoYhiIfhNcoV8I6V2Imb1l7UcurUb1vRdJuLC+Y6iOaXtjEwAPWD21h13rE1PtwNfE7nPoGGeWtbmaU6UB367BsjOWU4o0/h74+zz8//T4a8bIz/umph8K7rCjlltHldowp7wMmWew9SDTSqGzghYZfqGabtfNjkVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(166002)(66446008)(6916009)(478600001)(86362001)(8936002)(53546011)(6506007)(6512007)(66574015)(83380400001)(54906003)(4326008)(316002)(33656002)(76116006)(64756008)(5660300002)(26005)(36756003)(66476007)(91956017)(66946007)(186003)(8676002)(66556008)(2906002)(2616005)(6486002)(71200400001)(781001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?bXM2ZTg1RnZzZXF3K0VrM091OVFabFFEaHREWlFRRTFNdHFGVnNGZ3dUYXZx?= =?utf-8?B?TWs3WkhWRjhRUGhDQ3BjY2dnQ3VJRHpsbDR1c0tvVHpMaU5XcDRMNDNzRkRV?= =?utf-8?B?azU2aEk0TU5IcEJiUTg0cWZHMzZaeE9uS2Z5eGVUZElTRzZSQzFwK2R3c2Nz?= =?utf-8?B?cko1SEVrSkliczd6VUJtbXI3djZjY0pUSkJUU25zSkl6VkwybmxGYVUzdEt4?= =?utf-8?B?MXN3cHZCd09JSVRUc3BmTldsYVlvbldoekFhZVZoUFdKU0N3NS9uWFFoTjlt?= =?utf-8?B?RlBVTm85SHVkLzhpWGNFQm9ORDgwWTRiNUFOZ3FtbE5XWUdMZ3dEZjV0eTQ1?= =?utf-8?B?UFd2Nm5BMC9QWlFBbDRGMVJvb3lNbENIc0VnOVRoTFpBOUpkNjkwaTRPYUVP?= =?utf-8?B?MmNDdnM1bXA0K3haT0FxRmdwNE9Gb2tLNUNEWVpMRjJhWHlhMy9LeDVSaVdy?= =?utf-8?B?U0t5Qjh3WVJNTTFnVDU0T2ZISnQ5Y2tEYTJmQXhVanQ5eGVkZC8yMFdWQVJG?= =?utf-8?B?aFN0a2I2RXFnMHVOTFpIVzBXcDkrMzc0Q25UZFZ0UGxGalFyVEthdU5TUUtO?= =?utf-8?B?VTVnRC82UDVFR0FheWJxY2lIUThrSFhxMDdpdzNtd2RIQ1l1L0szZlIwNHhm?= =?utf-8?B?SmZzLzlOSGRuNUwyL0JEU2RnTGZUdVFBNDFyeWo3QXNBUHk3Q0NVSDVWanVE?= =?utf-8?B?dXNKWVJ0QlVTWnBxczMxWG5Rb1pORmlkVm4yQWVBRmNZNjF1cWk1ZExRQlgz?= =?utf-8?B?NkZyNHpIYUc5RHloT1RBaUtMcUE2ZHpJbEdDN3IzbUNkTVQ1Wk04OHMxSXB1?= =?utf-8?B?UkRrSmJITHVSUFV4RFpzczk2Q3VGM1NOazBiR1g0U0gxdEhvVEJJcFd5ams1?= =?utf-8?B?aUNiMkcwOGtMcGJsdFJBUHlzRjdWTFlUYjFCaW1qRkJTVGMrR1VkTTJXMGxa?= =?utf-8?B?bGZtMGs1Q1ZzL0dnOXpjOWtRS1F6RCtoOXVvREU3WkRYU0FRYmtWSzY3MWVY?= =?utf-8?B?SkR5U3R0NnZrdlphWVd1L2xJUVVUYTd4YVJNc243Y1Y4WkR3SEN3bDlBVDlL?= =?utf-8?B?M2E0M2d2cnNEUFhpR0dSVVNBeEt0LzhjV0EvTDFsd1B6QU5KQm5Bd1VnTHBY?= =?utf-8?B?enhVVUFlOTBDa3p0eTBhNFdjeHhOUjdSelVhWU85YWNGMEVCemN5UUNNUyt6?= =?utf-8?B?WU1hWndRRDBvVGJKN24ranQ0YVc2UUhVQ3R6VVdEMjZnNjNRNFJzZklWZGVK?= =?utf-8?B?UGN3M0VLcFJnRytqaTcweVpJME41VTQwTmlMaGhMbUdRblNLZlVwdVlHQjYy?= =?utf-8?Q?s6HmxmCpEDqiLLvla0o+7ed5pshcMcYGQZ?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_9D6268BDC5554B9AA8839B55EEB5D5DAjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e721375-64c9-4610-0955-08d8a13404e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 20:00:06.3810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ENOqCfGFXW+gUMr1jG3Gj9uqGXGOYMatYCHwS5jf8CxiK0Pl1Fa8z89jPQSNKIUJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6670
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-15_12:2020-12-15, 2020-12-15 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 phishscore=0 spamscore=0 clxscore=1015 adultscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012150133
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/vpCwaX_-Qd6KrH1PB9JiVYi6tso>
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: Tue, 15 Dec 2020 20:00:18 -0000

Hi Christoph,

On Dec 12, 2020, at 9:23 AM, Christoph Loibl <c@tix.at<mailto:c@tix.at>> wrote:

On 12.12.2020, at 15:07, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

No.

I guess, this may be the reason why we are having this conversation. ;-) This is why I am asking: Because from reading the RFC4271 Section 6.5 I would assume that not sending messages to the neighbor for HOLD TIME will *always* result in a HoldTimer_Expires event, that leads to a NOTIFICATION, release of all BGP resources, drop of TCP connection, … and no way to recover from that.

When he kicked off this thread Job cited a much older thread where this had been discussed. In the first message in *that* thread (https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/), Rob gives a rationale, a reasonable one in my opinion, for why it’s not safe to assume the session will be reset. Actually there are two reasons. Rob touches on one, which comes down to “if I explicitly tell you not to send anything to me, it is not reasonable to penalize you for not sending anything to me.” Admittedly, this requires some creativity in reading the spec (hint: you can pack a lot into your interpretation of “receive” in Section 6.5).

The second reason, however, is pragmatic and requires no creative spec interpretation at all. The window closing and staying closed for HOLDTIME might be a hint that the peer has lost its mind and can’t be counted on to run the protocol correctly anyway. Consider that one of the simplest reasons for failing to drain the socket would be that the daemon has fallen into an infinite loop. In such a situation, you can’t count on the peer’s behavior.

Also, a nit:

Isn’t it save to assume that if a system cannot send any messages to its BGP-neighbor (for whatever reason) for HOLD TIME seconds, that the neighbor on the other side has by that time already declared the BGP session dead (is already “trying" to deliver a NOTIFICATION

I think you are talking about this scenario. I’ll copy the example from Rob’s message cited above:


  rtr-A                   rtr-B
  (congested c-p)         (uncongested c-p)
  send window: >0         send window: 0
  recv window: 0          recv window: >0

In this case we expect:
 a) rtr-B does not send any BGP packet (KEEPALIVE/UPDATE/NOTIFICATION)
to rtr-A in normal operating circumstances.
 b) rtr-A does not expect any KEEPALIVE/UPDATE packets from rtr-B. The
session remains established even if no packet is received in the
holdtime.
 c) rtr-A continues to send KEEPALIVE packets to rtr-B.


You’re saying that you think Router A will declare Router B dead (debatable, but let’s assume it will), and that as a result it’ll produce a NOTIFICATION (yep). I’m not sure why then you say it would be “trying” to deliver that NOTIFICATION. Router B hasn’t closed its window, so Router A’s NOTIFICATION should be delivered — unless you want to stipulate other problems as well.

But this isn’t central to the discussion.

—John