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

[Alvaro Retana <[e-mail]>]

On March 22, 2021 at 4:14:55 PM, John Scudder wrote:


John:

Hi!

I'm just replying to this piece -- I'll take a look at the diffs soon.



> > 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.
>
> I’m inclined to leave this alone. I mean, we could go into that nuance, but
> then if some future specification extends the OPEN, do we have to go back
> and update this spec too? Better to leave it alone, I think. It is genuinely
> obvious, IMO, that you can’t encode more than the enclosing PDU format
> supports.

Can we at least take out "of any length"?  As you say, if someone else
changes the size of the OPEN message, the enclosing PDU will still
limit the size -- and it won't be "of any length".

BTW, now that I'm reading this again (and the next paragraph from
-10), I think the second sentence above is not needed at all (and how
can "MUST be prepared" be enforced anyway?).

OLD>
   In the event that the length of Optional Parameters in the BGP OPEN
   message does not exceed 255, the encodings of the base BGP
   specification [RFC4271] MUST be used without alteration.  However, an
   implementation MUST be prepared to accept an OPEN message that uses
   the encoding of this specification for Optional Parameters of any
   length.

   However, if the length of Optional Parameters in the BGP OPEN message
   does exceed 255, the OPEN message MUST be encoded according to the
   procedure below.

NEW>
   In the event that the length of Optional Parameters in the BGP OPEN
   message does not exceed 255, the encodings of the base BGP
   specification [RFC4271] MUST be used without alteration.

   However, if the length of Optional Parameters in the BGP OPEN message
   does exceed 255, the OPEN message MUST be encoded according to the
   procedure below.



> > 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.
>
> RFC 4271 left a lot to be desired in terms of nuanced error codes. I agree
> that we could introduce a subcode called something like “optional parameter
> field length mismatch” to be sent if the optional parameters length exceeds
> the unconsumed OPEN length. However, I’m disinclined to do it in this
> document, because it’s a pre-existing problem, it exists with the
> non-extended encoding as well, so any fix for it should really fix both
> cases. As such, it seems a funny fit for this doc.

As I said in my reply to Jeff, I'm ok with that not being included in
this document.


Thanks!

Alvaro.