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:24 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 29F3BC1522C3 for <idr@ietfa.amsl.com>; Mon, 16 Jan 2023 11:24:55 -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=unavailable 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 IFFhj11FM8-S for <idr@ietfa.amsl.com>; Mon, 16 Jan 2023 11:24:53 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6E5C14CE3E for <idr@ietf.org>; Mon, 16 Jan 2023 11:24:52 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 83EDB1E399; Mon, 16 Jan 2023 14:24:52 -0500 (EST)
Date: Mon, 16 Jan 2023 14:24:52 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Robert Raszuk <robert@raszuk.net>, Gyan Mishra <hayabusagsm@gmail.com>, Bruno Decraene <bruno.decraene@orange.com>, Donatas Abraitis <donatas.abraitis@hostinger.com>, IDR List <idr@ietf.org>
Message-ID: <20230116192451.GB19126@pfrc.org>
References: <CAOj+MMG9BuCBjATYNKO5H0oFUipCE8iBU+DJ0FLDDUZdp+nM3Q@mail.gmail.com> <C9D01C45-90BD-465D-B2C4-0CCA6B2A21A3@juniper.net> <CAOj+MMFrke5-9+pMKZ7QTawiOT+N3fD=2ta8hGEu=CG+qv_OQw@mail.gmail.com> <C264E12E-08DE-4C90-AF36-C0B477825DFE@juniper.net> <CAOj+MMF0R3dFZ+Wo9ymRXfeY1_0YyCWpdMf-WFXsbZ69wfAOaQ@mail.gmail.com> <B2FBC540-1F6C-481C-A421-DBD03DE28B04@juniper.net> <CAOj+MMG2PGtio-OHBOfadU8TnVrWaGD1sHBPZUD9SfGV5jRcpg@mail.gmail.com> <CABNhwV2wD1NE+ZzcbYvz80Mbg0gSELL_XYB+Zr9poN32mPo_JA@mail.gmail.com> <CAOj+MMH69nyL286y9kp7qcJCYju558xpYyT9-nNwXx2tod05DQ@mail.gmail.com> <BYAPR11MB32070EA7E779E37F40171E52C0C09@BYAPR11MB3207.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BYAPR11MB32070EA7E779E37F40171E52C0C09@BYAPR11MB3207.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/v1H2b-cqKUI1GYECCWUbuuCEHyg>
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:24:55 -0000

On Sun, Jan 15, 2023 at 07:28:33PM +0000, Jakob Heitz (jheitz) wrote:
> 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.
> 
> Graceful restart is affected. When a restarted session is restarted a second time,
> stale markings are removed. To prevent that, when a neighbor has previously restarted a session
> due to not supporting the new version parameter, a session that is restarted due to GR should not
> include the version parameter.

Whereas for exactly these reasons, I wouldn't want it in the optional
parameter.

John Scudder made most of the arguments I'd be supporting.  This is
optional, and capabilities say you should be ignoring things you don't
understand anyway.  Why force the implementation to hang up the session?

-- Jeff