Re: [Idr] Review of draft-abraitis-bgp-version-capability-07

"RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org> Fri, 21 August 2020 21:14 UTC

Return-Path: <rfc-ise@rfc-editor.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 D123C3A12D0 for <idr@ietfa.amsl.com>; Fri, 21 Aug 2020 14:14:41 -0700 (PDT)
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nrI-DSfDYrRW for <idr@ietfa.amsl.com>; Fri, 21 Aug 2020 14:14:40 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9863A12EC for <idr@ietf.org>; Fri, 21 Aug 2020 14:14:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 26615F407A0; Fri, 21 Aug 2020 14:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhaM0evXeyLs; Fri, 21 Aug 2020 14:14:13 -0700 (PDT)
Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 58F67F4079F; Fri, 21 Aug 2020 14:14:13 -0700 (PDT)
Received: from 81.174.197.1 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Fri, 21 Aug 2020 14:14:13 -0700
Message-ID: <934351064755453503645e7305e16784.squirrel@www.rfc-editor.org>
In-Reply-To: <CAOj+MME47tioGR9+vkzUsTPNgVj+g+LDH8zuuiBrLkdYaVyBqQ@mail.gmail.com>
References: <CAMMESswJfjShCjr0ZOhshWD058eosBAStOcXVAr77rv6RvFMDg@mail.gmail.com> <37f90ca874e87bd4f8b4245518cd3a3b.squirrel@www.rfc-editor.org> <CAMMESsyqTuPfxCMWO6GQCO8nc2z8+PxQVomL0HX0xQLrBLYEQA@mail.gmail.com> <63466e0fde345b64395b7d12c0ac40ca.squirrel@www.rfc-editor.org> <CAJwpseXeL4XsuaYDYsxRTa9XoO_SDpHZxM7LbNxhrH41XLV4-w@mail.gmail.com> <CAMMESswu=rFML41pYW-Gt_eyw+U_Aqmk+XsG4d5zPc_b7dVv9w@mail.gmail.com> <265604361b00db402c6a36bb895e4980.squirrel@www.rfc-editor.org> <CAJwpseVbr3bgH1jvZCUrcbzpcZVr8HCeXkfRtjA=4E2k=V48Ag@mail.gmail.com> <CAOj+MME47tioGR9+vkzUsTPNgVj+g+LDH8zuuiBrLkdYaVyBqQ@mail.gmail.com>
Date: Fri, 21 Aug 2020 14:14:13 -0700
From: "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
To: "Robert Raszuk" <robert@raszuk.net>
Cc: "Donatas Abraitis" <donatas.abraitis=40hostinger.com@dmarc.ietf.org>, rfc-ise@rfc-editor.org, "IDR List" <idr@ietf.org>
Reply-To: rfc-ise@rfc-editor.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0ehtyZm3Xp7MZuKkAaDNmmgnaKA>
Subject: Re: [Idr] Review of draft-abraitis-bgp-version-capability-07
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: Fri, 21 Aug 2020 21:14:47 -0000

I think I object to the idea that this is  bypass of IDR.

It is *still* not too late for IDR to pick up this work if they want to
(but it is very close to too late). What I would need to hear (and I
presume Alvaro as the responsible AD) is a clear statement that the WG
*does* want to work on this.

Robert, I read your email as saying that "I want roughly this function,
but I would not do it that way." (Please say if I misread you). That is
certainly possible, and the WG is never expected to approve work without
review and editing, but it is hard for an author who fails to get any
traction to be told much later that there is finally traction but only if
they discard their approach and start again.

Perhaps one of the perils of a FCFS registry is that codepoints are
relatively freely available and without WG control. But it isn't as though
the author did not put this up for review from IDR on several occasions.

Wrt draft-ietf-idr-operational-message, I note that this expired a few
days less than eight years ago. I think it is reasonable to assume that
the WG is not pursuing that idea.

Best,
Adrian

Robert Raszuk wrote:
>>
>> Not only iBGP. It's up to the administration scope. If that's a clos
>> topology of leaves and spines, most likely there will be eBGP used. >>
Or even especially routing on the host, or more complicated
>> Kubernetes/Docker deployments.
>>
>
> Sure not just iBGP but the draft says this: "This capability is NOT
> RECOMMENDED for eBGP use."  I realize what you meant to say was that
> the  draft is "NOT RECOMMENDED" to be used between different
> operational domains.
>
> - - -
>
> In any case this is an interesting case of IDR bypass. If this is
> approved I can already see a line of other proposals. Where will it
> bring BGP time will tell.
>
> My intention is however just to point out that this is a protocol
> extension which IDR compliant implementations will need to be aware
> of.
>
> The document uses a very soft language in a number of places. Example:
> The Capability Length SHOULD be no greater than 64.
>
> Bottom line is that there is a lot of people in IDR and/or GROW who
> think that we need to exchange such information between BGP peers. I
> am one of them. In the past I wrote BGP diagnostic message draft then
> we merged it with Advisory Message into BGP Operational Message which
> was in fact adopted as IDR WG document
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
> I think BGP (well really OS) version is a useful information, but I do
> not think this should be part of BGP Capabilities as an opaque text.
>
> My recommendation here is to add a new message to BGP Operational
> Message document and move forward with that more general solution to
> the problem. If FRR can support BGP Operational Message we can
> document it and move one step closer to IDR LC.

-- 
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org