Re: [Idr] AD Review of draft-ietf-idr-ext-opt-param-09

[Jeffrey Haas <[e-mail]>]

Alvaro,

On Thu, Mar 18, 2021 at 02:54:46PM -0700, Alvaro Retana wrote:
> 78	2.  Protocol Extensions
> ...
> 83	   In the event that the length of Optional Parameters in the BGP OPEN
> 84	   message does not exceed 255, the encodings of the base BGP
> 85	   specification [RFC4271] MUST be used without alteration.  However, an
> 86	   implementation MUST be prepared to accept an OPEN message that uses
> 87	   the encoding of this specification for Optional Parameters of any
> 88	   length.
> 
> [major] "MUST be prepared to accept an OPEN message...of any length."
> 
> The OPEN message is not covered by rfc8654, so the length is still
> limited to 4k...which means that the full Extended OP length/Parameter
> Length cannot be used.
> 
> Besides clarifying that, I think that new OPEN Message Error subcodes
> are needed for the cases where the length is invalid.  This type of
> error is possible in the non-extended version of the OPEN too -- I
> guess rfc4271 just assumed that this error would never happen.

Speaking as a vendor with an implementation here, we currently send
"Unsupported Optional Parameter".  A new sub-code would be fine to help with
diagnostics, but that's all it would do.  The BGP FSM is still getting a
NOTIFICATION to drop the session.

I think the headache you're highlighting is we have two conditions we can
get to here:

1. The length is unacceptable, but fits in the PDU.
2. There's an overrrun of the optional paramters vs. the encapsulating
   BGP message.


-- Jeff