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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

> Your argument sums to "capabilities negotiation can cause issues and I
may object to
> all features I don't like that may use capabilities".  Sorry, that's not
going to win in this discussion.

Nope. That is not my point. Neither is winning anything here :)

My point is to limit what is taken into BGP Capabilities for real and
critical to BGP functionality flags.

Sending any free form text - does not fall into that category.

>  I think what you're intending to type is encoding the version capability
in a new optional parameter
> different than a capability optional parameter.

Yes and I am not insisting on the choice of any specific encoding.

Kind regards,
R.













On Wed, Jan 11, 2023 at 4:55 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
> On Jan 11, 2023, at 10:35 AM, Robert Raszuk <[e-mail]> wrote:
>
> Hi Jeff,
>
> Yes your interpretation of my point is not cool.
>
> See I have been exposed to problems with capabilities in number of issues
> and it never is cool.
>
>
> It's no fun to be on the other end of the phone with a customer having
> such problems either. :-)
>
>
> Just noticed another public example:
>
>
> https://supportportal.juniper.net/s/article/BGP-session-between-Juniper-and-Cisco-devices-down-after-upgrading-to-Junos-OS-release-16-1?language=en_US
>
> Bottom line yes if one would take what it written in RFC5492 verbatim
> lot's of those issues could be avoided, but we are about impacting large
> operational networks hence a bit of resistance on my side to take it into
> BGP Capabilities especially considering that there are other alternatives
> with no obvious impact.
>
>
> Your argument sums to "capabilities negotiation can cause issues and I may
> object to all features I don't like that may use capabilities".  Sorry,
> that's not going to win in this discussion.
>
> I think we're all quite supportive of text that suggests operational knobs
> to disable the feature.  Since the text notes in section 3 that it has
> scenarios where it's NOT RECOMMENDED, it's leaning toward this needs to be
> configurable.  In general, the document could use an Operational
> Considerations section.
>
>
> Now if we want (as WG) provide input to authors I guess we could discuss
> pros and cons of either using extended optional params or as I suggested
> this week new BGP Open Optional Parameter. If we take this via WG to me the
> latter is more straightforward.
>
>
> To be clear, extended optional parameters from RFC 9072 is just about
> making additional length available for optional parameters.  I think what
> you're intending to type is encoding the version capability in a new
> optional parameter different than a capability optional parameter.
>
> -- Jeff
>
>