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

[Jeffrey Haas <[e-mail]>]

> On Jan 11, 2023, at 9:24 AM, Robert Raszuk <[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.
> 
> 
> If draft says that it can be send if it fits .. then if it does not fit it can be suppressed automatically I do not see how anyone can take it seriously and build any network automation around it. 

https://en.wikipedia.org/wiki/Argument_from_incredulity


> 
> Your math is off, especially in the face of extended optional parameters.
> 
> If you put it into rfc9072 then this is a different story. But currently it is not. And it is not good to potentially push BGP critical capabilities to extended space while free form text sits in the front among other 254 octets. 

It's almost as if this is an internet-draft and the author is seeking inputs to improve it.

Once you have the extended space, it's extended and you still have the same considerations as before: If it doesn't fit, you have to make choices.  Ordering is irrelevant for the capabilities.


> 
>> You are ok to punch holes in BGP Capability Negotiation for it ? 
> This comment makes no sense.  Try again.
> 
> Section 3 of RFC5492 does not have exclusions. 

exclusions to..?  Please try supplying some nouns, or better yet a full example of the concern.

>  
>> 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.
> 
> Ok. Assume node is upgraded and such capability is disabled on a peer. 

This again doesn't make sense.

If you don't support the capability in question, you ignore it.
If you support it, but don't want it, you ignore it.

-- Jeff