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

Alvaro Retana <> Fri, 21 August 2020 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F5153A126E; Fri, 21 Aug 2020 14:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MzNxL71XtQWQ; Fri, 21 Aug 2020 14:06:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67BB23A1261; Fri, 21 Aug 2020 14:06:21 -0700 (PDT)
Received: by with SMTP id m20so2673966eds.2; Fri, 21 Aug 2020 14:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=szagHN5dEw2XZSEu2mY5aTymUxUohNtkAJd+ylqmd7Y=; b=siX36V/AZKkXhrNYqVNH4nP+lF0xBdX7Bw7G2UsbY+66lorRRm1mVihTzaLeXax44b E44v17Tft/038yEDJyW0hTIJWgfEjnM4+qlq4bcwty4+G05ZlSD8tE1dYjZ9OZwAN2+e f0syZ5eo8HZtLX90SzmRkxecHMWhjsjp/RDP8FaG5WIz5smq7P1i1ARzYBnVBvCxTNgt i1FMEQocXA8qKjKJSnuePN5RGkR509N1fCUyjRvMJpKTJW2G0J9CkqUf8GgTcfZFyV0g Sv6b7F5kev0SULDwZTK8DIjCD36TyT2+xscJ3wHfPoqFR+gL8SLBJzS2rPK2i6aTx3qJ yy2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=szagHN5dEw2XZSEu2mY5aTymUxUohNtkAJd+ylqmd7Y=; b=nsrzG2d5l++fL4QLQhvyL0pvxfrlshLyn2oH/fqsqoNFBdkmnXbwWTqU51NroBeAJM Gn7qil5a+dQpzDr/r+miYiw9MuwzcH3e12xOuBRjBuxhhlKRlmyxsagBVCGnyYO56t/f Yqwg+x833PTNsnbH4nKoMXgrdDeut2aDGRKsA/JGTx78bvYtHBd3/4SziP1cNK3P9Xb6 sARVyNQkevLayETdq79GrauMU4JOJIadNCY2K2xkfRz/HbJn+rvzA5sEua2kJ++UwB/K iWdsXnSX9vj071joVIePj61QvdMAskYsknR9xeO0xbP5S/HOSeRYS8AA5bR8Pdx6O+nP ixoA==
X-Gm-Message-State: AOAM530nQMtyphaUNF0wZn3vYDpFt3m4imN0uTvtHBzgS6v/XIl+Nzpq OvGJ+XE+RhtFwNQRCCrpp2t1+jyL5RjYsqu4iZM=
X-Google-Smtp-Source: ABdhPJybD0P18qhSm3pUUm3VEfFjePJikSe/kUcVZuHuRa3YFm7MBg6HM72haWzgBquP4C+VXHl3bw2HQpncxxF664w=
X-Received: by 2002:a50:cd16:: with SMTP id z22mr4563167edi.155.1598043979865; Fri, 21 Aug 2020 14:06:19 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 21 Aug 2020 14:06:19 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Date: Fri, 21 Aug 2020 14:06:19 -0700
Message-ID: <>
To: Robert Raszuk <>, John Scudder <>, Susan Hares <>
Cc:, IDR List <>, Donatas Abraitis <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:06:24 -0000

On August 21, 2020 at 4:08:33 PM, Robert Raszuk wrote:

[Explicitly cc'ing the WG Chairs.]


Hi!  I hope you're doing well.

> In any case this is an interesting case of IDR bypass.

Let's please call things by their proper name.  As Adrian already
explained, the draft was initially brought to idr and there seemed to
be no interest in it [1].  The WG hasn't been bypassed, it just wasn't

Adrian also mentioned this:

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.

If there is now interest in progressing this work then a discussion on
the list is in order.  I'll let the WG Chairs lead it, if needed.

John/Sue:  What is your opinion?  Do we need time to discuss interest in idr?

> If this is approved I can already see a line of other proposals. Where will
> it bring BGP time will tell.

This is an interesting comment given that the WG recently processed
rfc8810 (Revision to Capability Codes Registration Procedures)
dedicating a significant portion of the registry to be assigned using
the First Come First Served procedure, which doesn't even require
technical documentation [rfc8126].   I didn't see any objections on
the list.

> My intention is however just to point out that this is a protocol extension
> which IDR compliant implementations will need to be aware of.

Just like other Capabilities, it is an optional extension.  rfc5492
already contemplates the existence of unknown or unsupported

I'll let the WG discuss the rest of your message.




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