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

[Alvaro Retana <[e-mail]>]

Jeff:

Yes, you’re right.

Are you suggesting that we don’t need that extension in this document, or
that we don’t need it at all?  I would be fine with it not being in this
document — not a high priority, but it is something we probably want to get
to at some point.

Thanks!

Alvaro.


On March 19, 2021 at 9:09:46 AM, Jeffrey Haas ([e-mail]) wrote:

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