Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

Ondrej Zajicek <> Thu, 08 August 2019 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B8BF1200E7 for <>; Thu, 8 Aug 2019 12:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIr1gztFWDpq for <>; Thu, 8 Aug 2019 12:13:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9BAB912002F for <>; Thu, 8 Aug 2019 12:13:49 -0700 (PDT)
Received: from feanor ( []) by (Postfix) with ESMTP id A97475FB8F; Thu, 8 Aug 2019 21:13:47 +0200 (CEST)
Date: Thu, 08 Aug 2019 21:13:46 +0200
From: Ondrej Zajicek <>
To: John Scudder <>
Cc: idr wg <>
Message-ID: <>
References: <000801d546f0$b9d27310$2d775930$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <>
X-Operating-System: Debian GNU/Linux
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)
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: Thu, 08 Aug 2019 19:13:52 -0000

On Tue, Jul 30, 2019 at 04:10:49PM +0000, John Scudder wrote:
> (As a co-author of course.)
> Since it seemed helpful last time, here's the elevator pitch for
> ext-opt-param: We are currently limited to 255 bytes of BGP capabilities.
> Since many/most BGP extensions want to use a capability, it’s not hard to
> imagine overrunning the 255 bytes.

AFAIK we are not currently limited to 255 bytes of BGP capabilities.

According to RFC 5492, multiple instances of capability options are
allowed, well-defined, just discouraged:

   The Capabilities Optional Parameter (OPEN Optional Parameter Type 2)
   SHOULD only be included in the OPEN message once. ... However,
   for backward compatibility, a BGP speaker MUST be prepared to receive
   an OPEN message that contains multiple Capabilities Optional
   Parameters, each of which contains one or more capabilities TLVs.

If i want to announce 2k bytes of BGP capabilities, i can just split it
to multiple sub-256 blocks of capability options. Real limits are 255 bytes
for each capability and 4k bytes for whole OPEN message.

While the draft removes per-capability limit by allowing to put all
capabilities ot one large option, it does that by backward-incompatible way,
while splitting capabilities to multiple options is backward-compatible.

Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email:
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
"To err is human -- to blame it on a computer is even more so."