Re: [Idr] New BGP capability to advertise running daemon version

Donatas Abraitis <donatas.abraitis@gmail.com> Fri, 02 August 2019 14:25 UTC

Return-Path: <donatas.abraitis@gmail.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 7CD1C120277 for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 07:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WvYn_BPWnQuH for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 07:25:07 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19080120256 for <idr@ietf.org>; Fri, 2 Aug 2019 07:25:07 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id h21so73998737qtn.13 for <idr@ietf.org>; Fri, 02 Aug 2019 07:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1qZMDTFEDIb2MhLV/vvwHv8oL9g5HXoc89/0I3tBny4=; b=Zag3Nhe4dU9mRYSUlEZQA56ZUUmsAjBR+2617q1MDJsGtFoiSYP5hEClitSpNZNaZx OwsH7lsmoepoLNtLILq1foST8r+sJrquWBr3uyle1NdSH5ANfT6RMxR0Ygbv7o56YZuO zCaAHkaLdWtqPR/GEK+jvBaKbsizhahETt3U/Ujl0DwtyCIVWSHHG9fzIXCvAv3/yx47 GUX4Se8S3KjolT7pHCWOi5k+eWY5uHoSZ/TK0QRubmEP3+K3cHJcqTBvcj2dd4VJKE3s 8fUzYOwKe+T497Uz5DHAMR+aYc+7PGysNQ4amO0iPjUUqx5U5TkX7SGXA36B4gqg3jxu COyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1qZMDTFEDIb2MhLV/vvwHv8oL9g5HXoc89/0I3tBny4=; b=iMeJddgxJlXgeXzN8SUg29RwHE3uuMDwEWJGn/9KnfgqAoWslbqkvmEuYzeHwuLwO+ tp3l2wqufFvhDyKxKCOecDJAbDJCbhnS8jG4oGtzhoQ6fME0I3mZrOCSj4gj06LOW4FI P+ohH7oEO26DFZhMwt1FutOAQRVA8KJK9nmqMP9gp/w0nGry73D5n5b7pukVhZIvVQa3 2dKAyY+maFJEgpL6uDZllAa4rh75X5Esxz/GGPOEgibFgLZWt+3hwD0lGgBcBZNjitYa 0yoVcc8fm3Bqze/DlFrMvbxryoRvev+gEjse73FyxyI3xLd3LdwNn35ddB4dc3MYcKiS WaYw==
X-Gm-Message-State: APjAAAWfvejBWotg1UeS6uoIAsC+BnZhzeawEb1ucclZSctYtjZ4HV/A /6YsH26cV5AmwP0E+iy7OpN5lrmUw6JJOgUYAIYq+Scu
X-Google-Smtp-Source: APXvYqxdM9CqM6M/jkxgzOaRc/qE+jMg9UGKQCdRWUD2NedHDeEDCEV870dmRxf46XCymdWxCfEm7MlB1SWpSx+cLH4=
X-Received: by 2002:a0c:acfb:: with SMTP id n56mr97669251qvc.87.1564755906087; Fri, 02 Aug 2019 07:25:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAPF+HwV3EEUza3FyiXsd_oSkj80OwY-tE2DgFWnynq1FL2tLHg@mail.gmail.com> <CAOj+MMHB4BTZqo3YgdrBHCg88RdymS_Xs9Z=XM5pADqh6-uwzg@mail.gmail.com>
In-Reply-To: <CAOj+MMHB4BTZqo3YgdrBHCg88RdymS_Xs9Z=XM5pADqh6-uwzg@mail.gmail.com>
From: Donatas Abraitis <donatas.abraitis@gmail.com>
Date: Fri, 2 Aug 2019 17:24:54 +0300
Message-ID: <CAPF+HwXzMUOF0D-4VFuJ+vkQ+26+1UcEM=fWU=R82M30qra0SA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/reLAXzICZzAMm4_EQ53G2Q0Uiks>
Subject: Re: [Idr] New BGP capability to advertise running daemon version
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, 02 Aug 2019 14:25:10 -0000

Hello guys,

Job, I posted revision 01 with your replaced text.

>In BGP protocol version number indicates the protocol version (ex BGP version 4) vs specific implementation build. Take Junos or IOS or EOS ... what is the version you would exchange in your extension ? The entire  operating system ?

It's not BGP protocol version, it's daemon/firmware version. So in
IOS/EOS/JunOS/etc. it would be like "CISCO 15.0(1)M8" or "JunOS
19.1R1". Device model, we can exchange using LLDP/CDP, but not a
specific version. Thus this would help in cases with lots of
heterogeneous devices.

>Also BGP capabilities are only locally exchanged - so hosts will tell TOR and that's it. You would still need to log in to 1000s of TORs to check which OS binary is running there. And when the hosts get's upgraded you start over.

One simple example is a single ToR device with 300 or 400 VMs under.
Each runs different versions BGP daemons. I noticed that few of 400
peers are down, how would you quickly identify which version or why
they are down? By having version in place it's easy to notice such
things and no need to log into those all 400 hosts in advance.

On Fri, Aug 2, 2019 at 2:04 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Donatas,
>
> In BGP protocol version number indicates the protocol version (ex BGP version 4) vs specific implementation build. Take Junos or IOS or EOS ... what is the version you would exchange in your extension ? The entire  operating system ?
>
> Moreover BGP implementation version which you are proposing to add to capabilities really means not much as even across identical protocol binaries specific BGP features may be enabled by configuration or may not resulting in different protocol behavior.
>
> Today you are already exchanging the enabled functionality of the protocol in BGP capabilities so it is just a matter of better show command to see across all peers what features are advertised and received by their real BGP capabilities.
>
> Now if you intend to locate bgp speakers which in some "version" may have bugs I am afraid much better way would be NMS for that.
>
> Also BGP capabilities are only locally exchanged - so hosts will tell TOR and that's it. You would still need to log in to 1000s of TORs to check which OS binary is running there. And when the hosts get's upgraded you start over.
>
> Much better option in your case - and possibly in other cases - would be perhaps to define new transitive BGP attribute or BGP wide community which would advertise [bgp_id + received capabilities + negotiated capabilities] across your domain.
>
> Then you will be able to use this information in a much more granular way and consistent across various BGP implementations.
>
> Thx,
> R.
>
>
> On Fri, Aug 2, 2019, 02:09 Donatas Abraitis <donatas.abraitis@gmail.com> wrote:
>>
>> Hi there!
>>
>> I would like to propose a new idea of how to simplify the debugging
>> process when dealing with lots of different BGP speakers and even more
>> with different versions.
>>
>> Basically, the implementation is very trivial, but it would be handy
>> in cases when you should debug why some functionality does not work
>> between two or more BGP speakers. Having this in place would speedup
>> troubleshooting time. Even better if that comes to automation to
>> gather information around all infrastructure you have.
>>
>> The implementation and details are posted in this draft:
>> https://www.ietf.org/id/draft-abraitis-bgp-version-capability-00.txt
>>
>> Waiting for comments.
>>
>> Thank you!
>>
>> --
>> Donatas
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr



-- 
Donatas