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

[Jeffrey Haas <[e-mail]>]

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