Extended Optional Parameters Length for BGP OPEN Message
RFC 9072
Yes
No Objection
Recuse
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
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
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
A couple of the sections of the Shepherd Writeup appear to have been skipped.
Robert Wilton No Objection
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
Thank you to Nancy Cam-Winget for the early SECDIR review.
Warren Kumari (was Discuss) No Objection
[ 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
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
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
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