IETF Logo Mail Archive

Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Linda Dunbar <linda.dunbar@futurewei.com> Sat, 21 January 2023 05:11 UTC

Return-Path: <linda.dunbar@futurewei.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 CD8ABC1524D8 for <idr@ietfa.amsl.com>; Fri, 20 Jan 2023 21:11:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 (1024-bit key) header.d=futurewei.com
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 D2Rpri2wL2Ps for <idr@ietfa.amsl.com>; Fri, 20 Jan 2023 21:10:59 -0800 (PST)
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam04on2132.outbound.protection.outlook.com [40.107.100.132]) (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 CC0F0C14F721 for <idr@ietf.org>; Fri, 20 Jan 2023 21:10:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wv04GQvzFFVSSTzF/KsqevsAE8T8m9p8GqNwwvd0bt2ubhqPlElJTi4jTSCSlyNjfEt20UJsyzkTVuspqjFjiu+z8H1hZni8xpbQzyIM4PAs2cWoi+O4Vy8lG8+AyOxH6gkGrJL5Ypm7h1VhJ/pUQrbOogjl2AwzyDyCXauUgXjcOK2zuMkdMjktK4mJbVIavRzN+ifcWff7KDC0Ci+pW5b44XFA5l3RINRhbDqHwm0USvHPb3ppvcyeWD/EyplRaG5vSwPmXgdycmQlVuwMtm0cgNN+HaPZ0PEf2xt42zmy7dMuHF0L1gXhGLLyiNOSISiogZGl6x6EoYt31a91hA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1iFfPUmdKAi5K+67HGiUJmkMkuJe67a+4WiaTsNsWmE=; b=C06m50YTLCbjOut/Ni4sTUyCA1lWFmWulnUCRxUQ61m6uE6jpI9fG69iVpL58+cvuI9QvG+pXE3KaE4jXAkWG4vCd3v/iCtLgB3kYiAqH6Vtu7ANdnvpxZFDOGScbnQvBzruFyZKEfERbt5HXMZhTAKYi0RgIp+/pEd+cGzNIHcofKzsiM7dCNjG38h4XA3uOZYaZn4+ymoCC2VEVAIPPXOqompwZSYoFniKpBnNHsq1NMuoo5Xp0JrCcAGYgd95MOICS95XQrB2ywCWh5YetoMesJnXcgfAJag+022yA2PvaXaJAK7ykSFxzVEXEEgFN/kZ5Q/KEXqm/aNyW2tdtA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1iFfPUmdKAi5K+67HGiUJmkMkuJe67a+4WiaTsNsWmE=; b=JdT0hU/b7qR8jxOc5Ein3RHf6werD8LltCj60o4HvlFYArXNaZBmlH9sH3ZNN7g7Gj+oAxzeUISR1bd9ZGMy9ErV5kaEj1iNEBP9lL/0Rp0lCLZWlrjBd0zEuhlo+Ho3N/hFSY5kuZD0UCXynj2hJBT5KX4gYJIV+kNGR0vKdww=
Received: from CO1PR13MB4920.namprd13.prod.outlook.com (2603:10b6:303:f7::17) by SJ0PR13MB5545.namprd13.prod.outlook.com (2603:10b6:a03:424::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.25; Sat, 21 Jan 2023 05:10:51 +0000
Received: from CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::d7f0:e736:a3bb:ec9d]) by CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::d7f0:e736:a3bb:ec9d%9]) with mapi id 15.20.6002.024; Sat, 21 Jan 2023 05:10:50 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Robert Raszuk <robert@raszuk.net>, Donatas Abraitis <donatas.abraitis@gmail.com>
CC: Gyan Mishra <hayabusagsm@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
Thread-Index: AQHZJMUAukiWNuqjCUO/fClfNNbbqK6Xjb2AgAAFNYCAAAHSAIAAAc6AgAA80ICAAAQ2gIAADWmAgAAjAwCAAAFGgIAAMTAAgAAG9QCAAAbgAIAAAk8AgAAO8gCAANNSAIAACmAAgAAHFACAAAQ2gIAABNwAgAAIiACAAAVegIAAA4QAgAACQoCAAAWTAIAAA3aAgAAKfgCAAA4igIAAHScAgAFpV4CAAAPaAIAARS+AgAGcLNCAAIkMgIAD+0JQgABto4CAAD59AIADmNeAgAAD4wCAAHHjEA==
Date: Sat, 21 Jan 2023 05:10:50 +0000
Message-ID: <CO1PR13MB49209C59FF4744F359F0C31985CA9@CO1PR13MB4920.namprd13.prod.outlook.com>
References: <FEF22BE4-8226-4286-AF7D-6B609D51E6BF@pfrc.org> <CAOj+MMH5C8zXZB=c9v57=M2Aa16cuyJY1EEMDHmX+T5FYq51mg@mail.gmail.com> <8D39FC71-043C-40A9-97D5-D71666611C5A@pfrc.org> <CAOj+MMFRVGde0k9dyW-gjMY1V3N6g8cpspnVLmhOHD557Qo6yw@mail.gmail.com> <A2FF27E6-403F-4606-84E8-A5305E434468@pfrc.org> <CAOj+MMH0LEds_UfVWAf59-JjRiPOYm=fozBx6ncmeSHTyMe11g@mail.gmail.com> <A1859410-8A3E-4CF9-A875-D432F7BEF1F0@pfrc.org> <CAOj+MMHhHB-K=hjEFwJTQ09K9dizkHaKfC79kJWikO=Eh8c1gw@mail.gmail.com> <20847254-3E13-49B3-942C-EE6EFDF993C1@pfrc.org> <CAOj+MMG9BuCBjATYNKO5H0oFUipCE8iBU+DJ0FLDDUZdp+nM3Q@mail.gmail.com> <Y77nmDKUgCUyhJ5W@diehard.n-r-g.com> <C3B4F29D-7C8D-4911-B140-286B7B8DA97B@pfrc.org> <CAOj+MMGmSBDwbxvSZ_x+j7NtCHRFFFvcCEKGJ0Wpis_OU26cLA@mail.gmail.com> <CABNhwV3qwCT8=8R+HTi1DFhbRN=FwHMF4XvQVowQwz=pb2U-nA@mail.gmail.com> <CAOj+MMG-5TT2sEnZVMabP1wA=gBNH0g9zkpoM9LWL7XFnh2aEQ@mail.gmail.com> <CABNhwV2H8Y7pthkWtJsDUN7ZscjGvc+v2XdpZ5CcG2ot9TBBog@mail.gmail.com> <CO1PR13MB492093DC7492BFD14A47C97B85C29@CO1PR13MB4920.namprd13.prod.outlook.com> <CABNhwV2UL0ruFeJwfwPnP7OWO9qCpHw3ubWNF7BoQQUEYEgZRw@mail.gmail.com> <CO1PR13MB4920CBF456034CE08D70691385C19@CO1PR13MB4920.namprd13.prod.outlook.com> <CABNhwV2MDq=ncxOfP1bi8t6wWq0kACupSPXaXO+QkdbUGzcWQw@mail.gmail.com> <CABNhwV31JTyycqdPCSPXidoq-0bd7ZHSZn_GRD2wUPtgLSXXSw@mail.gmail.com> <CAPF+HwXnzPErRKkAKYC=WAmyTXwWmyCAd7FPm5ZM7RZ=WHv72A@mail.gmail.com> <CAOj+MME-i_fZxBG9yNnno+Nrj=W9cfRKwGCFKyX=zQne+6N4pg@mail.gmail.com>
In-Reply-To: <CAOj+MME-i_fZxBG9yNnno+Nrj=W9cfRKwGCFKyX=zQne+6N4pg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR13MB4920:EE_|SJ0PR13MB5545:EE_
x-ms-office365-filtering-correlation-id: 38d4f1fa-5d4e-451e-ba0a-08dafb6ddd28
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FVsb7JgMcyqbuWuIrUY9d5QB0NAOFraBYZYZfuQPojHEY7+AdIpV7QaHFPywnLupBXs6OEQwxx6o1Cc2T356TCmmuydWA7ZR9UsqRDZSMFOCVtjbdMROl+Ho4rw1DuHDrjWG36G1/EthS68mgbrynQ3LakZBfWMMW55Doq8jDAq3BogjxAZVVkE7XaRTCnwK0Jw0pJz0Xc4CYw/ES0xTneWfrYXHTB2Yzo9skNcQYQMzzXH6Qf4CYhjtWyarDwlrWU9FCYTnLj0Mdil7OoXNZFNXuBfQhXCm2U5UsBAlourUfWr0CkyZAGAxMK4qQAfvbb7dKvWt+Suxnzyh0PXd377Ctb1uv6SN9UPWWvspw4vFDlOlvDIFAccFK/BhnfoFz1a6tzR4S7pi22Ewvx+HRBi9ndxyyDZ/wI4sD6goS9nipKh2+54cDsSkTZXpBfPVtqxYZrQd48W3cFJuBJI8gX9rfEQNuIikPnu01hYTS3x1v2PX/LYQ7o/cG2S2NC15WyVHLkinslgWR7N9wx+J+YRKWYKlmlBMGGpllJxFNvrnJkJDVpcvoArAY+oL5Vexfb2DwxJkAmIIVMQlhAe8MbDMgivFIqB6G+MhWo5997kq2bIICWAe29eGduYdynKkNyVERviMpjJBnigAaW2YPWEnQpB6bj3vjlKBqdtWZUIzoJsTi4Vo7eQiW3eiVbsHcXxdg+n2OMjUp26356m9iW5Hc8wGWLWUkBtsHy+mT9p3hg7gWgwEqaLjfygIo+wXqXAMxv1tGWZ6IKOtyWTZJHMndLSPrWBnKgn2damaRH4iixnxsnAT6Tbnuza4MCJb
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB4920.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(136003)(366004)(376002)(346002)(396003)(39840400004)(1690799008)(451199015)(5660300002)(44832011)(8936002)(4326008)(66556008)(8676002)(66476007)(64756008)(66446008)(66946007)(52536014)(76116006)(71200400001)(38100700002)(122000001)(186003)(6506007)(110136005)(2906002)(54906003)(9686003)(966005)(7696005)(316002)(478600001)(53546011)(83380400001)(41300700001)(86362001)(55016003)(166002)(38070700005)(33656002)(40140700001)(66574015)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: D9CV4oB2bpg9+KnR/AB7gFCjBXQZU+SSZOMbgxjG7S3FKqMSHjN468LAF/y8agEGKmozBEfa43bo50Lnk/CypQzdXVUvxN8uKkZqt3PBgz9ELt9C4Ei8N1RPxxY91jdBF9aDRYjJ9TJ3kV8RJGwxOKyWwirtWgeEO9eucI12deE31fZSS8bhFnobjUriMOO+6gPwCETdC9CIettiTJ/nhDkmBxISNu7TusdQU3wtRllQAJoaEuDxDkvAvQzFij57v+cDmwEU+zHOtZBR5Q8wwcvnVk3Yty83VHWnGeEZxdtueYd3QlKUDOQ0CNS1kGg+5XZoGb+/ATDRzBjvVMWtUEZbFCEZD1GqAVN199IZvaXdFO6yyslxgNoBL5+8v9/J11X7E9mEl3q9efLBk7doHucUqcbYPVQIPKXT+E8ILQ1MwiQx2cw3/Mk05kP3nT2p9IZxptbH93FJHsFSxD5r83qfHjlFz63W06UG4SnASr3rmoCl6138Ub0k9ZnUQ1FOHZ7pPMIuFF+4E9dBAWyqj/ab6hD8GFbU2rEj4ZBFsjSNEAOgqHfO2TFP18gOHvEc8yBn5k4twgDj6awPtdG0IXAy+uEgNWFMFGRO5/cVGiYYuDlKdt9FYUgvig0wnjQ3G3kBvXWLvd1iFQOOIpjaDxrAwONmGHwRWrz3VMuYXbqxZJoGQYtX6TfRfiHOfJ7poFmcHpam75y7rLZPasobWM0IEk0DsaKhxsOEa7ROd1iH8DBFCGA8mXEXLa6IqzxgxdPybSaO1B8L8/hZD+QEdsO7WSA8fp4lUXw0AiA/folJXldq37Xhs8HJgJm9PPoY2yXEtu6hDeTmrsLXBFGvxNFDTmj8YHggU6fy7xmZugYwp/f9oNvP8y/wdPLnlQ7JT5uZljv+FoTk5r7tDGgHy9hUYQQs0+Embt+Sm7az64xqVtn7QSA0DBcVxooLrNjnYLwEKXc/VNWKp+A0MLk9ptyhauGEtEWKO12WD52y1ICGsV0TkG2dmc6H9VEMCVm/Nhf3HXLUl7gKozFdRJ5bzi0oamJzxiLo84QL9seLwn8c3sK4/Rcu9iysNardfKRsvkfK0PlEaLYluKD7iBdVl8VMq2KBxAXtnFMFIO1Fd0CskMxJwL7wBVMmfsBEMFOBgBvTrGS8lflVo69CgUv5o6WHY2AjBudqtgbphpJAMPbjLQDUtKc0xsDmhTS3n/PYUIX3k0a473JCU7VIAuGsAFTwdiTeXdPUHr6f7vpAtVaKJE7NZwH7u4fDWzsNlYgszrNI9ZsSQC8Zne6FTJBYua/vIe6OLi9oUJ5GPDAmQDXaclsLf9LhrJsjKEjzdhX8cDrg29kE3HhtLNL3SvXtJwSv1iHAq05t4VBq+76+CYzLsU48oGPY9IEm8yfmd5pSrE1CV4HOOvYWcrF4iBKJ9ddgOF+pkV00tH+QMyX71OoWef5V1ddIeTHqPijfhVe2qJDeeES2jPItxtXXD98VgpLXWLt390WbeMzicalpXS726gFz2SlVbEwyMaFSpavcPBxuCjicJRsiJaDdLdLhV4KzQyCF3FHWuqS6QhQ++IRQQJZCm2yKiVcgzUavAz9Rnoe4e45EysjY5zEygLzsQhQyjxJde85BZ/vfBSzXHsc1cAkCLlVLtEUdJ/659IQp
Content-Type: multipart/alternative; boundary="_000_CO1PR13MB49209C59FF4744F359F0C31985CA9CO1PR13MB4920namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB4920.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 38d4f1fa-5d4e-451e-ba0a-08dafb6ddd28
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2023 05:10:50.6631 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WpT0ZEO7Yi9e9jazc/shcTLAmzTTMZIljQdhahmu2qKUnzaqiOB4W/QcRQnQxOHN/TsfqdX9yg0nuRQ42Fw+dQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR13MB5545
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kCc7W7G2rCGGd9uy9DJrNDaGPxc>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
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: Sat, 21 Jan 2023 05:11:03 -0000

Robert,

Per RFC4271:
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.

RFC 7606 doesn't change this behavior, does it?

Do most deployed implementations send "Subsequent OPEN" as you stated?
"Subsequent open would be tried without this new optional parameter"

Thank you,
Linda
From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, January 19, 2023 6:14 AM
To: Donatas Abraitis <donatas.abraitis@gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Linda Dunbar <linda.dunbar@futurewei.com>; idr@ietf.org
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25


> the session resets.

Well let's not forget that this is not like you would "reset" an established session

Basically with that BGP session would not come up which is different then to state "session reset". Subsequent open would be tried without this new optional parameter.

I find it actually a feature to be able to tell compute orchestration that it's BGP upstream understands this (or other capabilities) or not. Especially if this is not only to be used by humans but also with some automation. Spraying blind is questionable and very not deterministic.

Regards,
R.



On Thu, Jan 19, 2023 at 1:00 PM Donatas Abraitis <donatas.abraitis@gmail.com<mailto:donatas.abraitis@gmail.com>> wrote:
New version: https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-11<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-abraitis-bgp-version-capability-11&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HbFEPcKPZayFHNW8%2B30b32l2HQS5wg9JzujBlBbqhmg%3D&reserved=0>

TL;DR; Switched back to BGP Capability. Why? Because if the implementation does not support BGP OPEN Optional Parameters, the session resets. Also, added RFC9072 as a requirement to avoid exceeding 255 bytes of optional parameters length.

On Tue, Jan 17, 2023 at 7:05 AM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

At the top of RFC 4271 section 4.5 this is what I am reading that if any open or update message with error sub code is received the session is reset.


4.5<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4271%23section-4.5&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0ab58FJqIn33YQoxmEnMJw0eVxdhHezvvoeiZK8GmYQ%3D&reserved=0>.  NOTIFICATION Message Format



   A NOTIFICATION message is sent when an error condition is detected.

   The BGP connection is closed immediately after it is sent.





That goes for all of the sub codes



OPEN Message Error subcodes:



               1 - Unsupported Version Number.

               2 - Bad Peer AS.

               3 - Bad BGP Identifier.

               4 - Unsupported Optional Parameter.

               5 - [Deprecated - see Appendix A<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4271%23appendix-A&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HE9aoze3ZWIaGPikYmDd%2Bu8mCDd3oiD5k2WIE5MRvvs%3D&reserved=0>].

               6 - Unacceptable Hold Time.



      UPDATE Message Error subcodes:



               1 - Malformed Attribute List.

               2 - Unrecognized Well-known Attribute.

               3 - Missing Well-known Attribute.

               4 - Attribute Flags Error.

               5 - Attribute Length Error.

               6 - Invalid ORIGIN Attribute.

               7 - [Deprecated - see Appendix A<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc4271%23appendix-A&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HE9aoze3ZWIaGPikYmDd%2Bu8mCDd3oiD5k2WIE5MRvvs%3D&reserved=0>].

               8 - Invalid NEXT_HOP Attribute.

               9 - Optional Attribute Error.

              10 - Invalid Network Field.

              11 - Malformed AS_PATH.








On Mon, Jan 16, 2023 at 8:21 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

RFC 4271 section 4.5 states the session is reset for any open or update notification code.

RFC 7606 only updates error handling for update messages.  So the unsupported version number will cause the peer to reset.

Jakub mentioned this regarding the version capability draft which I agree is a good option below:

I can agree to using a new BGP OPEN Optional Parameter.

I would add that if after receiving the OPEN message, the BGP neighbor closes the session
with "Unsupported Optional Parameters", that the sender of that OPEN message try
opening the session again without the version parameter.

Kind Regards

Gyan

On Mon, Jan 16, 2023 at 1:54 PM Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:
Gyan,

RFC4271 states that if the version number is not supported, an error message should be sent. But RFC4271 didn't say if the BGP Open session should be failed.
I am just curious if BGP session can be started even if the  version number is not supported?

Linda

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Saturday, January 14, 2023 12:01 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hi Linda

Yes, RFC 7606 provides complete revision of error handling as opposed to peer reset which was the error handling with RFC 4271.

See section 2 and 3.

All BGP implementations including Open BGP implementations should support RFC 7606.

The main benefit for the versioning is in case the BGP peer capabilities exchange is in a one way state and not bidirectional and in that case having the version number would help troubleshoot if the AFI/SAFi, code-point or parameter is supported or not.

Kind Regards

Gyan

On Fri, Jan 13, 2023 at 4:52 PM Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>> wrote:
With so many BGP flavors and versions, is it possible to configure a router to ignore the capabilities that it doesn't support? But still keep the BGP session going?

Linda

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Gyan Mishra
Sent: Thursday, January 12, 2023 3:15 PM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25


So I think the crux of the issue is with so many open BGP flavors and versions and running into possibilities of feature support issues, I think it would be very helpful to be able to see the compute nodes bgp version from the TOR for troubleshooting.  In case their are known bugs with certain versions.

So if you were able to do a "show BGP summary" and are able to see the versions would be helpful.

Kind Regards

Gyan

On Thu, Jan 12, 2023 at 12:07 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Gyan,

> I can see a lot of value in this draft

So imagine you are a TOR.

Could you provide some examples on what would you do differently to compute
nodes speaking to you from BIRD BGP vs from exaBGP vs home grown Python BGP ?

Many thx,
R.







On Thu, Jan 12, 2023 at 5:53 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

I support the draft and agree this is very useful for cloud native environments.

I think the main use of this feature is for DC fabric extension to compute nodes and now as well Kubernetes microservices cloud native containerization or router in a container.

Just about every router vendor and ONF disaggregation vendor has a container version of router such as Cisco's XRD, Juniper cRPD, SONiC, Nokia, Arista etc which gives you both control plane and data plane to front and provide CNI networking for K8 Kubernetes microservices.

As well as you have all the Open BGP versions FRR, BIRD, Quagga, ExaBGP etc that  give you the BGP control plane to advertise routes using Linux data plane.

https://containerlab.dev/manual/kinds/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontainerlab.dev%2Fmanual%2Fkinds%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9ux95Fk3uk3WyY5t37EcgFsR5x60vZxi88erqUqruoM%3D&reserved=0>

So this version feature is really for cloud native compute layer NFV - VNF, CNF,  and not really for PNF  physical hardware based internet routers or switches.

I can see a lot of value in this draft and I support making a WG document versus independent stream based on the massive proliferation of distributed cloud native edge computing software based environments.

Kind Regards

Gyan

On Wed, Jan 11, 2023 at 2:20 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

> a feature that is useful from an operational standpoint

So let's put all the encoding aside. Your email made me curious why router A needs to know BGP release number, OS version and vendor name of router B ?

Are we doing such a bad job in IDR that BGP no longer interoperates at the protocol level ?

The original problem was presented as 1000s of computes reporting their BGP versions to TORs. But those 1000s of computes are already managed by orchestration which does have this information. Why should BGP TOR care ?

Or why IXP Route Server should care that customer X is connecting with Junos vs with Huawei vs with Arrcus to it or to other IX fabric members ?

Kind regards,
R.

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JrqZX2r6%2BBfkWLz5fuIA5BGCwgrP4CpvSCjlkGMFtXE%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Agh%2BQSIeWvCi3TO8WahYcEuTgWdyQG2o%2BhIARQKZkj8%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Agh%2BQSIeWvCi3TO8WahYcEuTgWdyQG2o%2BhIARQKZkj8%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Agh%2BQSIeWvCi3TO8WahYcEuTgWdyQG2o%2BhIARQKZkj8%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Agh%2BQSIeWvCi3TO8WahYcEuTgWdyQG2o%2BhIARQKZkj8%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Agh%2BQSIeWvCi3TO8WahYcEuTgWdyQG2o%2BhIARQKZkj8%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cdb02fdedb41d4f13da5308dafa16bbc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638097272811135708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JrqZX2r6%2BBfkWLz5fuIA5BGCwgrP4CpvSCjlkGMFtXE%3D&reserved=0>


--
Donatas

v2.23.0 | Report a Bug | By Email