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

[Robert Raszuk <[e-mail]>]

Sorry typo ..
s/is not cool. /is now cool./

On Wed, Jan 11, 2023 at 4:35 PM 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.
>
> 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
>>
>>