Skip to main content

Extended Optional Parameters Length for BGP OPEN Message
RFC 9072

Yes

Alvaro Retana

No Objection

Erik Kline
Francesca Palombini
(Martin Vigoureux)

Recuse

John Scudder

Note: This ballot was opened for revision 11 and is now closed.

Alvaro Retana Yes

Erik Kline No Objection

Francesca Palombini No Objection

Lars Eggert No Objection

Comment (2021-04-14 for -11)
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3, paragraph 3, nit:
-    it is not a bonafide Optional Parameter Type in the usual sense, and
+    it is not a bona fide Optional Parameter Type in the usual sense, and
+                    +

Martin Duke No Objection

Comment (2021-04-21 for -11)
I agree with Rob. Though not at all an expert on BGP, I think that if BGP nodes MUST NOT use the new encoding for smaller parameter sets, that is going to make it harder to test for the capability on the internet and reduce the incentives to support this specification. I would suggest that instead they SHOULD use the RFC4271 encoding, possibly discussing the reasons one might not.

Murray Kucherawy No Objection

Comment (2021-04-21 for -12)
A couple of the sections of the Shepherd Writeup appear to have been skipped.

Robert Wilton No Objection

Comment (2021-04-16 for -11)
Hi,

Thanks for this document, I found it relatively easy to read and understand even though I'm not particularly familiar with BGP.

There were a couple of areas of the document that I found slightly confusing, or inconsistent.  However, I do not feel strongly on these and will leave it to the authors/WG to decide how to handle these:

1. I found it slightly inconsistent that section 2 states:

   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.

and at the same time, section 3 states:

   It is not considered an error to receive an OPEN message whose
   Extended Optional Parameters Length value is less than or equal to
   255.

To me, I think this means that it would be better as a SHOULD rather than a MUST, or perhaps change section 3 to indicate that it a non-conformant encoding, but one that should be handled anyway.

2. 
   In parsing an OPEN message, if the one-octet "Optional Parameters
   Length" field is non-zero, a BGP speaker MUST use the value of the
   octet following the one-octet "Optional Parameters Length" field to
   determine both the encoding of the Optional Parameters length and the
   size of the "Parameter Length" field of individual Optional
   Parameters.  If the value of this field is 255, then the encoding
   described above is used for the Optional Parameters length.
   Otherwise the encoding defined in [RFC4271] is used.

I wasn't really sure what this paragraph was stating beyond what had already been stated previously in section 2, hence I'm wondering if it is required at all.  If it does remain then I found the reference to "Optional Parameters Length" is perhaps not as clear as it could be, and perhaps it would be better to refer to the "Non-Ext OP Len" field (as per the diagram), and perhaps to the "Non-Ext OP Type" field rather than the 'octet following the one-octet "Optional Parameters Length" field'.

Regards,
Rob

Roman Danyliw No Objection

Comment (2021-04-20 for -11)
Thank you to Nancy Cam-Winget for the early SECDIR review.

Warren Kumari (was Discuss) No Objection

Comment (2021-04-21 for -11)
[ Thank you for addressing my concern - clearing my DISCUSS]


Thank you for this document. It is clear, and solves a real problem.

Also, thanks to Al Morton for his OpsDir review - as always, it is much appreciated.

Zaheduzzaman Sarker No Objection

Comment (2021-04-21 for -11)
This was a quick read, thanks.

Comments:

  * Section 3 : 

        A warning MAY be logged.
    
     This is ambiguous to me, if this is not considered as Error then why there will be a warning. And it is also not clear what will be the warning about.

Éric Vyncke No Objection

Comment (2021-04-12 for -11)
Thank you for the work put into this document. It sounds like it is really a useful extension to BGP-4.

Having written that, I must admit that I failed to understand the mechanism at first reading. It took me a while to cross reference this doc + IANA registry + RFC 4271 (but, for sure, I am not a BGP SW engineer!).

I suggest to mention, in section 2, that the Code Capability IANA registry for 255 was reserved per RFC 8810 (so not causing interoperation) as well as using the actual values 255 in figure 1 and finally add the figure 4.2 from RFC 4271 to be crystal clear for the reader. 

Should the "new speaker" behavior be specified when an "old speaker" close the connection ? I.e., retry if possible without using this specification ?

I hope that this helps to improve the document,

Regards,

-éric

John Scudder Recuse

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2021-04-21 for -11)
Thanks for this short and sweet document; I have very little to say.

Section 2

And we're sure that a two-byte length is going to be enough "for ever",
right?

Section 3

   MUST NOT be used other than as described above.  If encountered as an
   actual Optional Parameter Type code, it MUST be treated as an

Is "actual Option Parameter Type code" synonymous with "in any position
other than the first option parameter type"?  In some sense "actual
Option Parameter" seems slightly under-specified.

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -11)