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

Robert Raszuk <> Fri, 21 August 2020 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14D183A119F for <>; Fri, 21 Aug 2020 13:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lqkS5SRvQvVe for <>; Fri, 21 Aug 2020 13:08:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BEE83A11A0 for <>; Fri, 21 Aug 2020 13:08:14 -0700 (PDT)
Received: by with SMTP id d6so3811061ejr.5 for <>; Fri, 21 Aug 2020 13:08:14 -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=gS3ccDJcV7joW3cqN8V+R8JmoiLY8iW0ee7VuYap6GQ=; b=ZyzS5Et++BYUii7L5c0JmXIxMM/MfJbnDq62JIHzkaJ/mLnz84XdHOUrzQ+cqKzQzf PCRkkC+fRiKbCMPCQEzuVzWPObtLFWAZLMBsoML8wn9FHkG5Mr4iY/wJnZnPMBlUA7m8 Z63UWHtLtUtRXwzM2zBBoN5yYGoxr5MnrapLF4AEGmsHEBo/TSl1l2Tcj1L1/fkg/lMZ FVifSnsGtkKLE1JzJvmrwp4+SVvlUftz/ERgJwXMhl9ZQu2tNo4NxfK/jtTVZni2vdAg zC1bJ3lmZG3KvQR1NQitt6bf19oTc9w23jXchQYChv7RbNmUEV446kdkZxa/LzyYEFdR 1FDw==
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=gS3ccDJcV7joW3cqN8V+R8JmoiLY8iW0ee7VuYap6GQ=; b=ZqOGPfidyzQtZqJBwA8gvjaUwnzRfeVxD9ky8dzGmYYbBONl+ritO2AlWKBwyXL2Fc O/fVmUmykXo9mnOiJk3g9M35JUSSr/mn4N553kOzvHN4yLnuGWKqSq7i0vHcriWUJKLf pE1+J1JJgymDkcFeQD79UAl84yuJvGV3y6Dq8WK+b4AZdW5B9iVCkdnUBkTv35NvmkSH 84SMQeNftgHKSCX1YZQuZKCemgAt5dDtOutepBCAWD9P+jOJwENjm5q+y9yftCHKgPnN pbj+auV47zF8KGzeDpayA61UHUjhFaVmRGqRpkuqIhdOcEU9jfkShmFJDLA6GACnAWWW aLxg==
X-Gm-Message-State: AOAM533DGBQU/J4gHiE6C5JN9f5e203b44LzAFJg7PXIcaUR/dyVpF3g emHoDN7655VJolUUZbkATpMROt9LyzYOZ04Lsz0sRQ==
X-Google-Smtp-Source: ABdhPJxM1BCi0pDe6CLiBRvAjYaiYK9hcKqBw4Z73J2jZI5dbY6hwC6Fm6NrZalwaa5u0FkAgjMDLnZyQxrjOYqXd28=
X-Received: by 2002:a17:906:8050:: with SMTP id x16mr4352904ejw.441.1598040492871; Fri, 21 Aug 2020 13:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 21 Aug 2020 22:08:02 +0200
Message-ID: <>
To: Donatas Abraitis <>
Cc:, IDR List <>
Content-Type: multipart/alternative; boundary="000000000000ea275205ad68cb49"
Archived-At: <>
Subject: Re: [Idr] Review of draft-abraitis-bgp-version-capability-07
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, 21 Aug 2020 20:08:18 -0000

> 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

- - -

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

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.

Kind regards,