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

[Robert Raszuk <[e-mail]>]

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.

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.

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.

Then what sounds like second open item (perhaps for a WG doc) to discuss is
structured vs unstructured nature of sent message.

Thx,
R.



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

>
>
> On Jan 11, 2023, at 10:14 AM, Robert Raszuk <[e-mail]> wrote:
>
>
>
>> exclusions to..?  Please try supplying some nouns, or better yet a full
>> example of the concern.
>>
>
> > If you don't support the capability in question, you ignore it.
> > If you support it, but don't want it, you ignore it.
>
> Here you go - explanation what I meant by punching holes which you
> neglected:
>
>
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.pdf
>
>
> "Punching holes" isn't clear.  However, you've at least provided an
> example of what you're talking about.
>
> From RFC 5492, Section 3:
>
>    If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer and terminate peering (see Section
>    "Extensions to Error Handling" for more details).  For example, a BGP
>    speaker may need to terminate peering if it established peering to
>    exchange IPv6 routes and determines that its peer does not support
>    Multiprotocol Extensions for BGP-4 [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>].  The Error Subcode in
>    the NOTIFICATION message is then set to Unsupported Capability.  The
>    message MUST contain the capability or capabilities that cause the
>    speaker to send the message.  The decision to send the message and
>    terminate the peering is local to the speaker.  If terminated, such
>    peering SHOULD NOT be re-established automatically.
>
> In the example cited in the URL, Enhanced Refresh (RFC 7313) was
> advertised and wasn't received.  RFC 7313 doesn't require bi-directional
> advertisement of the capability in order for BGP to come up, only to
> determine if the extension can be used between the peers.
>
> A better behavior, in my opinion, for the implementation when the feature
> isn't bi-directionally negotiated would be to let the session come up and
> simply not use the RFC 7313 functionality.  The implementation, however, is
> permitted to make such requirements if it wants to.
>
> If you argument is "any new capability may require bi-directional
> agreement to function", we have existence proof of compliant
> implementations of RFC 5492 that may do this.  Such implementations need to
> permit the ability to enable and disable capabilities/features and also
> have diagnostic tooling from the BGP NOTIFICATION codes to figure out how
> to get their sessions to come up.
>
> And if this is your observed problem, you have an issue with capabilities
> as a feature rather than this specific draft.
>
> -- Jeff
>
>