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

Robert Raszuk <> Fri, 21 August 2020 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BB693A1289 for <>; Fri, 21 Aug 2020 14:32:31 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R2s05OYXE8Ga for <>; Fri, 21 Aug 2020 14:32:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3264E3A12A9 for <>; Fri, 21 Aug 2020 14:32:28 -0700 (PDT)
Received: by with SMTP id bo3so4099797ejb.11 for <>; Fri, 21 Aug 2020 14:32:28 -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=UvnVMz14APVUeZHJrDe6tlzp6vACaf5k/2RaHvXJo7Y=; b=PecUD1gCOliI0KZY7plVUHGMxJA0HZTFIUGaTofPiqmCHfI32lC5t3gydbsQg9WZdN 1fjQl9uqoYKk02qWKVY87paprr7OR5W1UA7fHmcEBjVaKp1SDLe2e6SB+UXQbehPSFYX E6R/bJJkz4QnKojpl4KV8Zl/l682GWtmHNkmVqZhhGIAOYUOipyqxk7Z9QmywZfQB5w2 h12FonbRQxv68tlcicb68T0J/juakbJRqsZEmKkVY8ayNVBzNT8A4kXQ3xhuOR/N9RR2 RsmSlSxkyAJhPPl73RmYU357t5gP5bsELv8fjiSykLEnZtZ1Je4xHdQBIKZrzRbul6qw SEpQ==
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=UvnVMz14APVUeZHJrDe6tlzp6vACaf5k/2RaHvXJo7Y=; b=aAAqVLtadA5eZoqJnOcX45WLfSIkLWFJLvKskalOLc0C0UFwJzznBZUM+1SQlE+S6c 24eVYKzbubqeBdM/hCUdWbtLtD01ulkiVc5YY0FjKQ/+SvGOz3gMiruzLBAYKgvtRtAH gZxpjQ2mrubm6bFx/Sa2M6VcCathteGyPkHv1GvCzPeSiIfauOCh7CD2xKHFMPjG3d0/ m09oHhCxPzgJ4hxkb2udRIGFbnjCDsulYWgAC14aH1KSYmWGbI4kXDycB4Cm6K6jN7Qt X8a4XD5pDVdtzF+6ynorkvNQk/jbjbFPJyxGb/7sxwNjLqcU0la0wL0FnAmx5DFjXRVU BmLw==
X-Gm-Message-State: AOAM532Zzs9Zwh5d4d1nogRiiVUtbSlOzR22bQ3NkVZCKs7tX4FWLQr9 YkLkppuBVQvQbJYYqiHHuy0ifvXIL0LiuFKGOaNtRA==
X-Google-Smtp-Source: ABdhPJypckXr8UTKLlRTRL2Y+5EZCvYw0z8VxZKI+o8swMjZIlhSxkhiDuio88DIBdfGNTz3cXnI0N6VPPCYvX/lsUE=
X-Received: by 2002:a17:906:970e:: with SMTP id k14mr4492231ejx.417.1598045547215; Fri, 21 Aug 2020 14:32:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 21 Aug 2020 23:32:16 +0200
Message-ID: <>
Cc: Donatas Abraitis <>, IDR List <>
Content-Type: multipart/alternative; boundary="0000000000002d582805ad69f9ea"
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 21:32:31 -0000

Dear Adrian, All,

I think there is a significant difference between documenting that some
extension is useful from stating this is useful and MUST be done this way.

Also I am not sure what Alvaro expects IDR and chairs to do here. To adopt
the draft which insists on using BGP Capabilities to carry a free form text
when there may not be rough consensus to do so ?

Or maybe to take a problem at hand and work together to produce a solution
which may not use BGP Capabilities at all ?

Network audit tools are really cool to have, but just like some recent
attempts to turn BGP into config push is BGP a good protocol to exchange
OS/BGP code version information between peers ? And as I asked and no one
answered what if the problem is caused by 1 session away ?

> 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.

In my books the document is stable for some time and waiting for

It seems rather a norm that some documents take 10+ years to get processed
here. Hint: pls just look at the history of BGP Optimal Route Reflection
document history. So 8 years seems still pretty nominal to me ;)


PS. As to the use of "bypass" term I did not mean to say that this has been
hidden in any form or shape ... quite contrary. WG says this is not good
solution then going around WG is what I call a bypass.

On Fri, Aug 21, 2020 at 11:14 PM RFC ISE (Adrian Farrel) <> wrote:

> 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
> >
> >
> > 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),