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

Jeffrey Haas <jhaas@pfrc.org> Mon, 16 January 2023 19:21 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 C260EC1522C3 for <idr@ietfa.amsl.com>; Mon, 16 Jan 2023 11:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ugHwVeb__kRf for <idr@ietfa.amsl.com>; Mon, 16 Jan 2023 11:21:54 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 01457C14CE3E for <idr@ietf.org>; Mon, 16 Jan 2023 11:21:53 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 12D2A1E399; Mon, 16 Jan 2023 14:21:52 -0500 (EST)
Date: Mon, 16 Jan 2023 14:21:52 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20230116192152.GA19126@pfrc.org>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CO1PR13MB4920CBF456034CE08D70691385C19@CO1PR13MB4920.namprd13.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IEBnTEeg2R0GUb6QF1-mR3JburI>
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: Mon, 16 Jan 2023 19:21:54 -0000

Linda,

On Mon, Jan 16, 2023 at 06:54:29PM +0000, Linda Dunbar wrote:
> 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?

RFC 4271, §6.2:
: 6.2.  OPEN Message Error Handling
: 
:    All errors detected while processing the OPEN message MUST be
:    indicated by sending the NOTIFICATION message with the Error Code
:    OPEN Message Error.  The Error Subcode elaborates on the specific
:    nature of the error.
: 
:    If the version number in the Version field of the received OPEN
:    message is not supported, then the Error Subcode MUST be set to
:    Unsupported Version Number.  The Data field is a 2-octet unsigned
:    integer, which indicates the largest, locally-supported version
:    number less than the version the remote BGP peer bid (as indicated in
:    the received OPEN message), or if the smallest, locally-supported
:    version number is greater than the version the remote BGP peer bid,
:    then the smallest, locally-supported version number.

Tersely, if you don't support the right version number, you hang up the
session with a NOTIFICATION and leave enough of a breadcrumb that the next
OPEN could arrive at a possibly mutually supported version.

-- Jeff