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

[Jeffrey Haas <[e-mail]>]

Robert,

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