Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Jeffrey Haas <> Thu, 29 October 2020 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6641E3A0B49 for <>; Thu, 29 Oct 2020 04:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ssRJ7xFlorEP for <>; Thu, 29 Oct 2020 04:18:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E344E3A0AF7 for <>; Thu, 29 Oct 2020 04:18:04 -0700 (PDT)
Received: by (Postfix, from userid 1001) id CBAE21E354; Thu, 29 Oct 2020 07:33:16 -0400 (EDT)
Date: Thu, 29 Oct 2020 07:33:16 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: John Scudder <>, IDR List <>, Donatas Abraitis <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25
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, 29 Oct 2020 11:18:07 -0000


On Thu, Oct 29, 2020 at 09:22:29AM +0100, Robert Raszuk wrote:
> > - I think requiring extended optional params is a good idea for this.  It
> >   mitigates the necessity for having to do do the math to squeeze stuff in
> >   or not.
> How about we would just carry a fixed size URL reference to this
> effectively static and opaque to the bgp protocol information instead of
> actual text string ?

I think this is problematic in a few senses:
- Sure, you could take this idea to the extreme that we'll just have a
  single four-byte field with a FCFS registry that everyone uses and has
  private space for a local registry.  And people would hate that.  You're
  devolving to pre-registration for something that may change frequently.
- Sure, you could just reserve char version[64] in the structure, but domain
  names may vary in length.  And when you move to punycode i18n domains,
  this could be even messier.  See prior issues with RFC 8203.
- I strongly expect that some operators will want to stick in their own
  strings here.  "Role" potentially in combination with "version".

> IMO anything which is static and is not needed for protocol operations,
> best path selection etc ... should be passed as a pointer.
> Fetching such string could be done in spare CPU times well before need to
> locally present it or at the run time when someone executes a show cmd or
> other form of query api.

Which is really a lot of typing to say "we're not exchanging this out of
band ... why?"  Which is still a legitimate argument.  It's why I think the
use case, although slightly helpful, has a lot of weaknesses.  

The one slight boost I give the core use case that we're regularly seeing in
data center cases is protocol stacks are being spun up with very little
additional components. This provides a push to consolidate channels for
sending critical information.

-- Jeff