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

[Donatas Abraitis <[e-mail]>]

>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