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

[Alvaro Retana <[e-mail]>]

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

[Explicitly cc'ing the WG Chairs.]


Robert:

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

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


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

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/search/?q=%22draft-abraitis-bgp-version-capability%22



> 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
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00
>
> 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.