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

[Robert Raszuk <[e-mail]>]

No it is not.

Jeff thinks it is fine. But that is his opinion.

Thx,
R.

On Wed, Jan 11, 2023 at 3:23 PM Donatas Abraitis <[e-mail]>
wrote:

> >I'm willing to receive it and potentially just throw it on the floor. I
> might even be willing to burn the 255 bytes of space in a buffer in my bgp
> peer data structure for it after running it through the same sanitizer we
> do for RFC 9003.
>
> I'm confused now. In the past, we discussed that this is _very_ bad
> approach using Capability, now it's fine to go?
>
> On Wed, Jan 11, 2023 at 4:08 PM Jeffrey Haas <[e-mail]> wrote:
>
>>
>>
>> On Jan 11, 2023, at 8:52 AM, Robert Raszuk <[e-mail]> wrote:
>>
>> Jeff,
>>
>> > My personal preference?  Capability, adopted by the WG.
>>
>> Just to make sure I got it correctly ...
>>
>> You are willing to send free form text as BGP Capability ?
>>
>>
>> I'm willing to receive it and potentially just throw it on the floor. I
>> might even be willing to burn the 255 bytes of space in a buffer in my bgp
>> peer data structure for it after running it through the same sanitizer we
>> do for RFC 9003.
>>
>>
>> You are ok to burn 25% of space designated for BGP Capabilites ?
>>
>>
>> Your math is off, especially in the face of extended optional parameters.
>>
>>
>> You are ok to punch holes in BGP Capability Negotiation for it ?
>>
>>
>> This comment makes no sense.  Try again.
>>
>>
>> You are willing or not willing to suppres Unsuported Capability when such
>> is received on non upgraded node ?
>>
>>
>> You're encouraged to go re-read last paragraph of section 3 of RFC 5492.
>>
>>
>> etc ...
>>
>> What if tomorrow we will see another draft asking for FCFS type from
>> https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
>> to support other free form text there ? I bet there is tons of other stuff
>> compute nodes are willing to share with the network ...
>>
>>
>> Oh, probably so.
>>
>> The job of the chairs of a working group where the code points are FCFS
>> is to make sure that the request is a reasonable one.  This includes
>> avoiding duplication of work if there are prior features covering the code
>> point request.  If there's reason to say no, the IESG and IANA will likely
>> support us.    And, as stewards of the code point space, we also are here
>> to make sure that code points aren't exhausted for bad reasons.
>>
>> In other words, there's reasonable discretion.
>>
>> The same holds true of a BGP implementation.  If the remote
>> implementation doesn't support extended optional parameters, then the
>> sending implementation should make wise choices as to what it places in the
>> limited space it has available.  And even in the most of 4k space that's
>> available for extended optional parameters, if stuff doesn't fit and it
>> keeps the session from coming up?  That implementation is likely to not get
>> deployed very well one would think.
>>
>> -- Jeff
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> --
> Donatas
>