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

[Robert Raszuk <[e-mail]>]

Hi Donatas,

Two comments:

> It is unstructured data and can be formatted in any way that the
implementor decides.

While nice for the sender may not be easy on the receiver. I would rather
not hint on any formatting here if you choose not to make it as part of the
spec.

> :~# vtysh -c 'show ip bgp summary failed'
>   ...
>   Neighbor EstdCnt DropCnt ResetTime Reason
>   ens192         3       3  00:00:35 Waiting for peer OPEN (n/a)
>   ens224         3       3  00:01:12 Waiting for NHT (FRRouting 7.2)
>   eth0           3       3  00:00:14 Neighbor deleted (FRRouting 7.3)

That may be easy to show on the figure then to make it happen in the
implemntations due to max screen size. If now the field is up to 255 octets
(or even if it was up to 64 octets) this simply may not fit in already
loaded "show bgp summary" output.

Last - while I hinted that you may take it back to IDR this is truely the
decision to the chairs and WG. At least now the major blocker IMO are gone
so you should consult with chairs on the recommended track for this draft.

Many thx,
R.


On Tue, Jan 10, 2023 at 5:13 PM Donatas Abraitis <
[e-mail]> wrote:

> Robert, thanks for the suggestions.
>
> New version
> https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-09
>
> Basically modified Capability -> OPEN Optional Parameter.
>
> On Tue, Jan 10, 2023 at 2:35 PM Robert Raszuk <[e-mail]> wrote:
>
>> Hi Donatas,
>>
>> From my pov if you are willing to switch encoding to new type of BGP Open
>> Optional Parameter this could go in fast track of IDR too. Seems useful and
>> not very harmful. And requires just few lines of changes to the draft :)
>>
>> And while doing those changes you can delete section 3.1 entirely and
>> extend this to use 255 octets to be even more useful. If you like you could
>> divide this space into few blocks: OS-NAME, OS-VERSION etc ...
>>
>> Cheers,
>> R.
>>
>>
>>
>>
>>
>> On Tue, Jan 10, 2023 at 1:29 PM Donatas Abraitis <
>> [e-mail]> wrote:
>>
>>> An additional Open Optional Parameter sounds good to me also. Robert, do
>>> you agree on moving this direction + ISE track?
>>>
>>> On Tue, Jan 10, 2023 at 2:23 PM Robert Raszuk <[e-mail]> wrote:
>>>
>>>> All,
>>>>
>>>> In order not to repeat the points made and vastly ignored in this
>>>> thread before in Sep 2020 I do think that what is proposed should NOT be
>>>> carried in BGP Capabilities.
>>>>
>>>> Instead if authors would like to proceed I suggest to carry it in new *BGP
>>>> Message Type* (perhaps Informational as we have this written out
>>>> already) or at least as a new *BGP Open Optional Parameter Type (not
>>>> as BGP Capability Type 2)*.
>>>>
>>>> Stuffing 64 octets of free form text  into BGP Capabilites, while
>>>> breaking current BGP Capabilities functionality for opaque stuff seems
>>>> completely unjustified.
>>>>
>>>> Regards,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 10, 2023 at 1:04 PM Alvaro Retana <[e-mail]>
>>>> wrote:
>>>>
>>>>> On January 10, 2023 at 2:27:34 AM, Donatas Abraitis wrote:
>>>>>
>>>>>
>>>>> Donatas:
>>>>>
>>>>> Hi!
>>>>>
>>>>> > I'm still concerned and want to get back to this idea somehow, it's
>>>>> really
>>>>> > convenient.
>>>>> >
>>>>> > > PS1. And on the other hand if it is not adopted here it will
>>>>> likely get
>>>>> > > published as an RFC anyway in the ISE track.
>>>>> >
>>>>> > Who can help me with how to proceed this way as ISE track?
>>>>>
>>>>> Taking a document through the ISE track is a DIY job -- send email to
>>>>> [e-mail]; the process is here:
>>>>> https://www.rfc-editor.org/about/independent/
>>>>>
>>>>>
>>>>> Adrian is not the ISE anymore, so please point Eliot Lear (the new
>>>>> ISE) to this thread.  You can cc me for any additional background that
>>>>> may be needed.
>>>>>
>>>>> Thanks!!
>>>>>
>>>>> Alvaro.
>>>>>
>>>>
>>>
>>> --
>>>
>>> *Donatas Abraitis*
>>> *Principal Systems Engineer*
>>> @: [e-mail]
>>> W: www.hostinger.com
>>>
>>>
>>> This message and its attachments may contain privileged and confidential
>>> information. If you are not the intended recipient, do not use, copy, or
>>> disclose this information. Please notify the sender and permanently delete
>>> the message from your system.
>>
>>
>
> --
>
> *Donatas Abraitis*
> *Principal Systems Engineer*
> @: [e-mail]
> W: www.hostinger.com
>
>
> This message and its attachments may contain privileged and confidential
> information. If you are not the intended recipient, do not use, copy, or
> disclose this information. Please notify the sender and permanently delete
> the message from your system.