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

tom petch <ietfc@btconnect.com> Wed, 28 April 2021 16:02 UTC

Return-Path: <ietfc@btconnect.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 B79163A130E for <idr@ietfa.amsl.com>; Wed, 28 Apr 2021 09:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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=btconnect.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 Xez5m1rWLzqA for <idr@ietfa.amsl.com>; Wed, 28 Apr 2021 09:02:06 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::70d]) (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 0F5743A1254 for <idr@ietf.org>; Wed, 28 Apr 2021 09:02:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VNZvWosdRnU/ZagrHdI1I3md5fcZhyTFv9TqUm3yRYHXxiOL6P4w9AhoBRZqcd1Li3mYJ6V81SNGlXsBivqcvkoca0ru+1kCuV37kGDa8e/UPZn1+Uf34RjlfiPfOC+WgqQUlIU82Htkg1EwoubeO8BeOBr6Uuc3Gjv3ep0ekDI+CwtUmQLe2nW6uLY4bUop0lSFYBn+5AD2ncHp47GVwKqeOnyBAahWOW6Hy7+KbMMVR7E3bQzrlnwKQQNoHV5pBATlC6Gv2gxAeZz7shKQf96+mhPGLz0fXBsF2xST1SN0eCd39ywkjQnihQB9/sAhNMBwqDnYS+eiLiJkRA+qkQ==
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=xOMTgL6kaepZvNIMW7M+MLhMIhkuvGI/aPkUwhcTaTw=; b=H9v9sxn7WEq9UI7BUFpXmVx/axHTWRV3J3ryQj+pni1exWUpa1MVgwE9I/JpbUhQ9GWiClUWTSVLK+0R4KwpQCQ622HTlorjtUzbw8VYBPmhRk6TSCPV0KmwTct5X9RoiiGZxDsErV7P0bSIAfqwJHgM8Ne0ZNSpKsSealYJBUAMgZVAOmKAihJHywWAtdm65g8bG0AXWtUWrmzdBn/nodG9a1H+Y65ZfEaetAY3h10m/Pv6nSM6XBvhcIUZBWBbq6z5a+U1TzrSaZt2vsu6TMQ7LvDs0LFEt/wz8YBZL9hvGP8RJtD+U92afKZhQXvdgZu2U+FnLySH339nUIDIxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xOMTgL6kaepZvNIMW7M+MLhMIhkuvGI/aPkUwhcTaTw=; b=uocQfbZilWi5h/Y4vLeSB6kO/a0IgSZ1T828MKH9CX13AXMRD7m5A6NT4uO7dgRVEfTq7AMaJqfy8X5l4qcIPm3U8NKw6/j7qhJ9TPNDW26E0a5ZbENwUsDoMd6fwCki1j3TkLhPbdVW1N87aaMg2Fd7nL3yV0aNMIOEHy0jtVg=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AS8PR07MB7413.eurprd07.prod.outlook.com (2603:10a6:20b:28a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.22; Wed, 28 Apr 2021 16:01:57 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%4]) with mapi id 15.20.4087.025; Wed, 28 Apr 2021 16:01:56 +0000
From: tom petch <ietfc@btconnect.com>
To: Robert Raszuk <robert@raszuk.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>
CC: "idr@ietf. org" <idr@ietf.org>, Ben Cox <ben=40benjojo.co.uk@dmarc.ietf.org>
Thread-Topic: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested
Thread-Index: AQHXNeyWuL85GQc5306CuZDl5UxM3KrCogwAgAAQnICAACiggIAFeWm4gADGwQCAAKo6AIAAWvJ+
Date: Wed, 28 Apr 2021 16:01:56 +0000
Message-ID: <AM7PR07MB62482A4E83C32BCAA1F95F94A0409@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <CAL=9YSVy+mvxvAv+maxkUSzPbe0bfnUy-XJJTtcVhi3S3bm=WQ@mail.gmail.com> <20210423212348.GB19004@pfrc.org> <CAOj+MMGH+y-gxSLaakknWSPFLEk9ikkUU1fa=3H0FjkokAbg3w@mail.gmail.com> <20210424004838.GC19004@pfrc.org> <CAOj+MMH5yzpPZjdUcfXV4cxCORqCsQY4X+niBjnwxjPfN-tsJA@mail.gmail.com> <BYAPR11MB3207E4A0BDC3367E21886C55C0439@BYAPR11MB3207.namprd11.prod.outlook.com> <20210427124724.GA21146@pfrc.org> <BYAPR11MB32077A59B783B81E5D4D2297C0409@BYAPR11MB3207.namprd11.prod.outlook.com>, <CAOj+MMG9Nz=FEMr+HNm2A6T3bGRw4qnds_3FU9ZqV9Uisfozuw@mail.gmail.com>
In-Reply-To: <CAOj+MMG9Nz=FEMr+HNm2A6T3bGRw4qnds_3FU9ZqV9Uisfozuw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.143.250.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cef04351-7e39-41c4-4db3-08d90a5ef2eb
x-ms-traffictypediagnostic: AS8PR07MB7413:
x-microsoft-antispam-prvs: <AS8PR07MB74135D4961301837A0EED3ADA0409@AS8PR07MB7413.eurprd07.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: tkQhXEsdfEP4VgqyS2vJvXyLk46svU93gvz7duZr/EuC75IUoFe3JUxlSNlCBbLuk5bnTppqPWc9brEiq83eRxTccRVw5WMaQmGkQqsVNz1PLK/Ipb82ZetNIe65Or1G552mjgzizyFWM0wIxuOZp1niKL/wFMB+/HE1lGByhk7SWhpn9e3gHePugUHr8knjpBDFPV+3s+yvtS0tB5TGNdltIVJBjmtBhU4htuBPOCw0iE62LY2ApHBo6saMxhMDfaNoUmaZ2+TBwFRONVp9EPNcLocZFVkqstrgNz8JBCrzm325VU56cxvvcsrikcNgfcxyXnqsBwgVE8f8NHMAcq6jqWdIaBxQOVWrz89JzbmpgTWb6LClO+ichVFiwbeTfNgymo8moy8BcXWmtK6wr/XU2pqHfD6Ck074Tf4fYtHfzj5CFQ4zZ2zNz9DuDPEBDvHSqeb0evGiKObSQNL0cS04vA75Y26i79WkqokERtMx4/3WjH9RKPaPkqgD1bdStdInfs6Yrvt3T1IVzbjorRUP0bJX2UBx1/+qBfdBKA96ly30KezNZnNvuMTuA2m7QM+tmqwkspaQa9Ou4DDg2b/T9gC8zCXTXjrFnvkHFj8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(366004)(346002)(39860400002)(64756008)(66476007)(66556008)(66946007)(38100700002)(86362001)(7696005)(91956017)(5660300002)(66446008)(66574015)(76116006)(6506007)(478600001)(52536014)(71200400001)(26005)(83380400001)(4326008)(122000001)(33656002)(2906002)(8676002)(316002)(110136005)(55016002)(8936002)(186003)(54906003)(9686003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?YIpngTVwR/3QzfL0/4ADEDA6E1/fvTYYSH1Low5oDWkL+EUWe1DqTRZ9K6?= =?iso-8859-1?Q?3M5XN0qOqd6GZcc0pwsIzaLgXgAZ/1N2f6MeRq2T01EfRUycgi1dXZMUsQ?= =?iso-8859-1?Q?O9ykOdXh01y2JLkUQalCvy+c6hFB8xFdHMNYCkowSNXma9VVfeP/DhIK3v?= =?iso-8859-1?Q?D92e3tZHOOcR2BN6f5Hc7elFy+Nlg20/fR74FPXDoUznPeCASpBdKDgGGM?= =?iso-8859-1?Q?RTJ++xlW9gl0G44rGUzA546NxaRpWe8rYfEtYBvXaYAJn6TD5lGdzDz2Tu?= =?iso-8859-1?Q?94L1yF2Fd2HTQe71Cd9Uc4M3hwm5QARW/9TePhM2TiD+5aZzi1yP3OD1HP?= =?iso-8859-1?Q?OZzbgHiLym8QBOG1R/WhXZNgxUi4tUhy1mT3GfzWzFj2T0xqT/z7Wh0kTu?= =?iso-8859-1?Q?+yWRcoEQ8BBzmwucOOvdUYB1avt14YRVaTgEJ4fs0SSQbpe+wnWNzxYkS7?= =?iso-8859-1?Q?jlL8cUkjEx8W5ohVUANTQJdXOpGCq1BgwnwWC1f71vSDvWN09MVMF8hDA5?= =?iso-8859-1?Q?Q1/sK3H1xFnn9ZfuSpcIzMNT65pNdO7hir8uJJmEzYH/GdNgDIVkCVBsrE?= =?iso-8859-1?Q?LT6i6RwDJglYgiL4LT7jAJBhKxHoBrhbfo4qAekrNC7lTkW7Du2L/lvy9j?= =?iso-8859-1?Q?7dINQfEZhJn9vPrIbUQwGqrk/EYmNlJ8rp6WqXtH6VLaMEgbZGP7ps1rT7?= =?iso-8859-1?Q?XznZGeiQG3wWh8i+VRooteS1LSdEieNc4vYAz1rvSdp6XCAdBVynBJz3xn?= =?iso-8859-1?Q?aYXUt4A+Rt3FAvZONTkLyXtndkgVNzFSktzS5CV8onG/8Q1uE620TLfNyk?= =?iso-8859-1?Q?dHqsHt4sEJGAS/jgaULq5SktKZAraplnkMR9zmik/WWg4XMweerAeZa7kY?= =?iso-8859-1?Q?vkNXC9PH+UiIUcuIdYux0g3HoX8uM0FugqYDM3HW2Ygkrem8jVv1eDEELl?= =?iso-8859-1?Q?KzmEs3WG3KiWDwc8Y/EgaX4cRLHl/om6KmjTdpZ9rvgmOCmC5k0rs49/aS?= =?iso-8859-1?Q?B8dhBrRcMBKeKYfZtsCnHCJcgFjsdgIT1xbt2WXvZtp3xKYEZTCwd6PlGJ?= =?iso-8859-1?Q?2MuUSS9xoUxUU/YIwsO1SbZizbDxoRLAZX0db8POYmHMT0zwtY2l4uo9mk?= =?iso-8859-1?Q?fy6BnRgugY6QhpYvEMSkMqD/MHyMdndNqYpyr361TMX6h469efZPMVVLnI?= =?iso-8859-1?Q?bPSvrpsI6W0rxJz0U0qm8p2xyWPxyl0wiTmI/f4gFYjWHh3s+uq9HPw2pp?= =?iso-8859-1?Q?yPgk6gqJThxl8TH6QlkWljSMDPy+Xb/94JWIOgFNbPl3WmQQR81XO9Cjva?= =?iso-8859-1?Q?C0xPtMkQ3D5V8f2rIQGO8nWnuI3wZrIxLotOYenBUC4mFHQ=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cef04351-7e39-41c4-4db3-08d90a5ef2eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 16:01:56.7649 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Tvob0GnnoD0X3Bq61Ui/lS3yoqFE8nQRQOGF5jhxWfEeIfOds3VOuc31o7SB5zU8LFsbNbviE9NT9dnAqhZxZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB7413
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cmNVHUzJLCACPynebUC3cUHiPYs>
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: Wed, 28 Apr 2021 16:02:17 -0000

From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Sent: 28 April 2021 11:25

I think the default should be a long timer and to retain the routes
when resetting the session. However, this choice should be configurable.

There could be potentially another option ...

Once we can not write to a peer over existing TCP session we could try to OPEN a new TCP session to the same address:179 with the same security strings. We could use same or different BGP_ID.

<tp>
As per RFC4271, that sets up a second FSM and leads to connection collision and the shutdown of one system, the one being dependent on who initiated the stuck session, so it could fall to the stuck system to act, except it is stuck so it cannot.

I have not seen an analysis of exactly what has gone wrong but cannot help thinking that it could well be a bug, in TCP or BGP, in the peer in which case expecting rational behaviour of it might be expecting too much.

A different approach, leading on from this idea, would be to reserve another TCP port number for BGP use which BGP could use to check out whether or not it can establish a TCP connection with the peer.  If not, then the peer is beyond help.  (TCP ports are a scarce resource but then functioning BGP is rather important to the health of the Internet).  If it can establish a TCP connection, then there are plenty of options available.

Tom Petch

/* When we discussed eBGP peering between VRFs of the same PE it was confirmed that most if not all implementations (at that time) do not check for different BGP_ID when accepting an OPEN). */

If a new session succeeds and we sync routes we are good. Old session can be terminated. No data plane disruption at all.

If not it would be indeed a sign that peer's BGP is not doing that well and perhaps confirmation that in some deployment situations it would be good to remove him from the picture after draining his routes from our peers.

Best,
R.