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

"RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org> Fri, 21 August 2020 19:43 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 E3AB73A14A3 for <idr@ietfa.amsl.com>; Fri, 21 Aug 2020 12:43:38 -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 ZQJS4l9p3qf8 for <idr@ietfa.amsl.com>; Fri, 21 Aug 2020 12:43:37 -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 5B7173A126A for <idr@ietf.org>; Fri, 21 Aug 2020 12:43:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 2DBF4F40798; Fri, 21 Aug 2020 12:42:44 -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 OSNsKZ_GteaB; Fri, 21 Aug 2020 12:42:40 -0700 (PDT)
Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id CC25DF40796; Fri, 21 Aug 2020 12:42:39 -0700 (PDT)
Received: from 81.174.197.1 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Fri, 21 Aug 2020 12:42:40 -0700
Message-ID: <220ba30b4e9f6980a4a1d67b1f891abf.squirrel@www.rfc-editor.org>
In-Reply-To: <CAOj+MMGZahye9xhSEAFOjoDyUHnDVZNqt0-QA3zXoE-7MNLTVg@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> <CAOj+MMGZahye9xhSEAFOjoDyUHnDVZNqt0-QA3zXoE-7MNLTVg@mail.gmail.com>
Date: Fri, 21 Aug 2020 12:42:40 -0700
From: "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
To: "Robert Raszuk" <robert@raszuk.net>
Cc: "Alvaro Retana" <aretana.ietf@gmail.com>, "Donatas Abraitis" <donatas.abraitis@hostinger.com>, 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/ob78UYday_rmtq9ptx6j_oqq4EM>
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 19:43:46 -0000

Hello Robert,

>> The IESG will consider this document on Sep/10
>
> May I ask why are we skipping normal process to go via IDR with this
> draft ?

It's a valid question.

After several attempts, the IDR WG was not apparently willing to adopt
this idea. The chairs confirmed this, and the author brought the work to
the Independent Stream.

Note that on 20191121 I sent mail to IDR ("Cross-check wrt
draft-abraitis-bgp-version-capability") to give a heads-up on this plan.

> Also looking at latest published version why status of this doc is
> "Informational" if essentially this is a protocol extension?

The Independent Stream is not capable of producing Standards Track RFCs.
This "protocol extension" using a FCFS code point is, therefore,
documented in an Informational RFC to describe what has been implemented
and how to use/interoperate with it.

> Last - if this is to be enabled only for iBGP does this mean that we
> are endorsing networks which do not know in their NMS what version of
> operating systems is deployed on a given network element?

I don't think that "we" are endorsing anything. This document is stating
what has been implemented.

We could discuss adding text to say that "In many networks, it might be
expected that the NMS would have full knowledge of the deployed operating
system versions on each router in the network. This mechanism provides a
way to verify that information and operate in the absence of a coordinated
NMS." I'm not sure how helpful such text would be.

> And for
> manual CLI based iBGP session troubleshooting how does it help to know
> the version of route reflector if problem with received UPDATES or
> WITHDRAWS can be generated one iBGP hop behind it?

I'll leave Donatas to answer that one.

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