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

[Donatas Abraitis <[e-mail]>]

A new version submitted:
https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-16.
TL;DR; Added more implementations (ExaBGP).

On Fri, May 24, 2024 at 11:03 AM Donatas Abraitis <
[e-mail]> wrote:

> Hi All,
>
> submitted a new version
> https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-15
> .
>
> TL;DR; Added more implementations, the version should be a non-null
> terminated string, and dropped the figure which was a bit misleading and
> not needed at all because the length is encoded directly into capability's
> length.
>
> On Wed, Nov 8, 2023 at 2:52 PM Donatas Abraitis <
> [e-mail]> wrote:
>
>> Hi, folks!
>>
>> I want to get back to this draft and hear the final thoughts on this.
>> Speaking with some people in IETF118, this seems reasonable giving one more
>> chance. In short: there are already 4 or 5 open-source implementations
>> supporting this BGP capability, and Wireshark (maybe more from the
>> observability tools) has it too. The motivation is quite simple: very
>> trivial and fast to implement while giving a useful information set for the
>> operators.
>>
>> Thanks!
>>
>> On Wed, Jan 25, 2023 at 9:46 PM Donatas Abraitis <
>> [e-mail]> wrote:
>>
>>> >I think the name “version” is too close to the BGP version that peers
>>> negotiate.
>>>
>>> I disagree. "BGP version"  == Protocol version, while "Software Version"
>>> == Software, running BGP protocol, version.
>>>
>>> On Wed, Jan 25, 2023 at 7:01 PM Linda Dunbar <[e-mail]>
>>> wrote:
>>>
>>>> Donatas,
>>>>
>>>>
>>>>
>>>> I think the name “version” is too close to the BGP version that peers
>>>> negotiate.
>>>>
>>>>
>>>>
>>>> Why not use “debugging capability”?
>>>>
>>>>
>>>>
>>>> Linda
>>>>
>>>>
>>>>
>>>> *From:* Donatas Abraitis <[e-mail]>
>>>> *Sent:* Wednesday, January 25, 2023 7:46 AM
>>>> *To:* Robert Raszuk <[e-mail]>
>>>> *Cc:* Linda Dunbar <[e-mail]>; Gyan Mishra <
>>>> [e-mail]>; [e-mail]
>>>> *Subject:* Re: [Idr] WG adoption call for
>>>> draft-abraitis-bgp-version-capability-08, to end September 25
>>>>
>>>>
>>>>
>>>> Quick update: IANA has assigned Software Version Capability number
>>>> (75), updated:
>>>> https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability
>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-abraitis-bgp-version-capability&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cfc943f52c4ff4981008608dafeda80ad%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638102511702204675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JIpgyvd7WKfFTLpZY%2FsAxJP5y9qGR5Ob7MTkCi61S9s%3D&reserved=0>
>>>> .
>>>>
>>>>
>>>>
>>>> On Sat, Jan 21, 2023 at 1:19 PM Robert Raszuk <[e-mail]>
>>>> wrote:
>>>>
>>>> Linda,
>>>>
>>>>
>>>>
>>>> Per RFC4271:
>>>>
>>>> *A NOTIFICATION message is sent when an error condition is detected. **The
>>>> BGP connection is closed immediately** after it is sent.*
>>>>
>>>>
>>>>
>>>> This is a general statement. You can't take it out of the current
>>>> context.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Do most deployed implementations send “Subsequent OPEN” as you stated?
>>>>
>>>> *“Subsequent open would be tried without this new optional parameter”*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Again we are discussing the addition of a new extension. Such addition
>>>> can define in itself what implementation should do when receiving such a
>>>> NOTIFICATION message indicating that peer does not understand the new
>>>> extension.
>>>>
>>>>
>>>>
>>>> Rgs,
>>>>
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Donatas
>>>>
>>>
>>>
>>> --
>>> Donatas
>>>
>>
>>
>> --
>> Donatas
>>
>
>
> --
> Donatas
>


-- 
Donatas