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

[Robert Raszuk <[e-mail]>]

Right and I think this is good. I do not like sending anything into vacuum.

For clarity to some folks: That includes BGP OPEN Optional Parameter Type 2
as well.

The below was more referring to Linda's question.

Cheers,
R.

On Mon, Jan 16, 2023 at 8:34 PM Donatas Abraitis <[e-mail]>
wrote:

> I can speak on FRR, the implementation resets the session if an
> unrecognized BGP OPEN optional parameter is received.
>
> On Mon, Jan 16, 2023 at 9:28 PM Robert Raszuk <[e-mail]> wrote:
>
>> I am afraid you are talking about BGP version while Linda is asking about
>> the subject draft bgp version ... Both are completely unrelated "versions".
>>
>> While we are here I did reread RFC4271 and I am not sure either if there
>> is text to mandate closing the session when new BGP OPEN Optional Parameter
>> is not recognized. Neither does FSM. Generating NOTIFICATION and continue
>> should be allowed by the spec unless I missed some embedded mandate to
>> close it.
>>
>> Thx,
>> R.
>>
>> On Mon, Jan 16, 2023 at 8:21 PM Jeffrey Haas <[e-mail]> wrote:
>>
>>> Linda,
>>>
>>> On Mon, Jan 16, 2023 at 06:54:29PM +0000, Linda Dunbar wrote:
>>> > RFC4271 states that if the version number is not supported, an error
>>> message should be sent. But RFC4271 didn't say if the BGP Open session
>>> should be failed.
>>> > I am just curious if BGP session can be started even if the  version
>>> number is not supported?
>>>
>>> RFC 4271, §6.2:
>>> : 6.2.  OPEN Message Error Handling
>>> :
>>> :    All errors detected while processing the OPEN message MUST be
>>> :    indicated by sending the NOTIFICATION message with the Error Code
>>> :    OPEN Message Error.  The Error Subcode elaborates on the specific
>>> :    nature of the error.
>>> :
>>> :    If the version number in the Version field of the received OPEN
>>> :    message is not supported, then the Error Subcode MUST be set to
>>> :    Unsupported Version Number.  The Data field is a 2-octet unsigned
>>> :    integer, which indicates the largest, locally-supported version
>>> :    number less than the version the remote BGP peer bid (as indicated
>>> in
>>> :    the received OPEN message), or if the smallest, locally-supported
>>> :    version number is greater than the version the remote BGP peer bid,
>>> :    then the smallest, locally-supported version number.
>>>
>>> Tersely, if you don't support the right version number, you hang up the
>>> session with a NOTIFICATION and leave enough of a breadcrumb that the
>>> next
>>> OPEN could arrive at a possibly mutually supported version.
>>>
>>> -- Jeff
>>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> --
> Donatas
>