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

Ondrej Zajicek <santiago@crfreenet.org> Thu, 08 August 2019 19:13 UTC

Return-Path: <santiago@crfreenet.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8BF1200E7 for <idr@ietfa.amsl.com>; Thu, 8 Aug 2019 12:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIr1gztFWDpq for <idr@ietfa.amsl.com>; Thu, 8 Aug 2019 12:13:49 -0700 (PDT)
Received: from mail.crfreenet.org (varda.crfreenet.org [81.92.145.160]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB912002F for <idr@ietf.org>; Thu, 8 Aug 2019 12:13:49 -0700 (PDT)
Received: from feanor (feanor-poda.crfreenet.org [164.215.121.182]) by mail.crfreenet.org (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 <santiago@crfreenet.org>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: idr wg <idr@ietf.org>
Message-ID: <20190808191346.GA20497@feanor.crfreenet.org>
References: <000801d546f0$b9d27310$2d775930$@ndzh.com> <1F967C41-2164-4FB7-813F-9DB41245BE6A@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1F967C41-2164-4FB7-813F-9DB41245BE6A@juniper.net>
X-Operating-System: Debian GNU/Linux
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1-E-q3MQ0-DtMKhBbr0qqyTz0TA>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."