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

[Donatas Abraitis <[e-mail]>]

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