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

Robert Raszuk <> Fri, 02 August 2019 11:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D19FC120096 for <>; Fri, 2 Aug 2019 04:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RVIO2ffxF6vP for <>; Fri, 2 Aug 2019 04:04:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71D1C12004A for <>; Fri, 2 Aug 2019 04:04:35 -0700 (PDT)
Received: by with SMTP id d17so73296854qtj.8 for <>; Fri, 02 Aug 2019 04:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vRjBfi6e4RVSzf8Bed3dKwR676sAuxQMmWNFHXzz3zE=; b=a1+a06akcVdOkn1EnskMb9Umxh+77MUa1oAF5qGpiuMdkogljOtBm3w7va7pSgClDV aa2VHniFjMxtKYsVyUCO2dAkeEjjxa82q8KmxfTE3zvj//5wAav9L1d3r4VoStZmNsSX RdgeNtLeuu0Finjf+8xOk5ZdUQZE/BwyeqPXvWWnzzI82L8CgdrJOHY73+biOcthTkRA 0pdAAGl82B82uFwe3Vda2Y8GwoP+NELNAx3ZFkuauX8SCik/qK7xke51yRM1l/KtvkpZ m8k9CoT3Cjge15NIttHOyMrTFjyie5t3zsLSr65SJPxJzPSYKnWg0mNHSnw0yk1JhMxk 4mdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vRjBfi6e4RVSzf8Bed3dKwR676sAuxQMmWNFHXzz3zE=; b=HRLLfqNPd6fwMCCLdQkGYYeYbkxQn77eoCPTTpxTjpBqUp9GkOxu+/QhaK2rEb7cWD UAdM6i3snONDI1OMHPm9Z99zK9zYAvQhp/Q7tVuqvWmEvwGs0bMMuNhCvfC2K1QGSxZp +0+cPI0yK84szwUrBkM4qoZYsklPOhEc19gz7OCd5ZLIhAlivqwp7BGr5G+xT9rhQmaR 5hczElF272BS09pph43BMwMsrMh2wIBueQujmA6mvx/O1Y3YWMjot54dIkKCfaXa7C7P FFf7iZ5auWQuHrYhWk1wt9kHbUVA6bCK2Pne7/BwDDNMdP8bg9+3tsGAu8DCQBpgDd8w Lvuw==
X-Gm-Message-State: APjAAAXwSCPbbI6IEDPDw1DZ8SAiFWyTAiId/LTtON0sOjwToEel+QS3 hI/jutDJ5TdhQbcQ/csSVToeKYXZJM+cLIjKfpYpTw==
X-Google-Smtp-Source: APXvYqwKtxxQcIKFPj3Z7BqL+2QD88e3WXHNEZPg022NqMq17Za9eTUl47chu21JRyzYXqG2vcb2wp1+crcO5mSsZTM=
X-Received: by 2002:aed:228d:: with SMTP id p13mr94523860qtc.208.1564743874375; Fri, 02 Aug 2019 04:04:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 2 Aug 2019 07:04:23 -0400
Message-ID: <>
To: Donatas Abraitis <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000cc060a058f205289"
Archived-At: <>
Subject: Re: [Idr] New BGP capability to advertise running daemon version
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Aug 2019 11:04:38 -0000

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.


On Fri, Aug 2, 2019, 02:09 Donatas Abraitis <>

> 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:
> Waiting for comments.
> Thank you!
> --
> Donatas
> _______________________________________________
> Idr mailing list