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

[Robert Raszuk <[e-mail]>]

> - 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 ?

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.

Note that till one day dynamic capabilities are in place - the above would
also cover ISSU/NSR where one would like to do software upgrade without BGP
session reset.

Thx,
R.


On Wed, Oct 28, 2020 at 10:38 PM Jeffrey Haas <[e-mail]> wrote:

> Adding in a comment as I clear my backlog:
>
> On Mon, Sep 28, 2020 at 06:18:21PM +0000, John Scudder wrote:
> > It seems to me that the discussion hasn’t concluded and we are still
> having productive discussion. Hence, I would like to extend the period for
> discussion by another week, now to conclude on October 2.
>
> I have general concerns about this feature.  But let me offer related
> observations why my opinion is "not a fan, but of potential use":
>
> - This capability is advertised prior to session establishment.
>   RFC 8203 got a bit of jutification for putting in text during a
>   NOTIFICATION where the session is going down anyway.  Having this at
>   session start means less chance for damange than if we're exchanging
> stuff a
>   bit more interactively in something like the operational message.
> - 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.
>
> I would qualify the feature as "mostly harmless" and "useful in some
> circumstancs".  Use in BGP fabrics is one I find a compelling use case.
>
> I'm strongly supportive of the concerns with using this feature for general
> ISP eBGP use cases.  I will, however, offer the related observation that an
> ISP may like knowing what version of software their customers are running.
> It may ease situations where service providers may want to signal a
> customer
> to upgrade a vulnerable stack.
>
> Consider me weakly supportive of adoption and fast WGLC.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>