Extended Message Support for BGP
draft-ietf-idr-bgp-extended-messages-36
Note: This ballot was opened for revision 33 and is now closed.
Alvaro Retana Yes
(Ignas Bagdonas) No Objection
Deborah Brungard No Objection
Alissa Cooper No Objection
Comment (2019-08-06 for -35)
'When propagating that UPDATE onward to a neighbor which has not advertised the BGP Extended Message capability, the speaker SHOULD try to reduce the outgoing message size by removing attributes eligible under the "attribute discard" approach of [RFC7606].' This might be a bit clearer if it were to explain that "eligibility" is not limited to malformed attributes (since RFC 7606 could be read as having that limitation).
Roman Danyliw No Objection
Comment (2019-08-07 for -35)
No email
send info
send info
A nit in Section 4: Per “A BGP UPDATE will (policy, best path, etc., allowing) typically propagate throughout the BGP speaking Internet”, the parenthetical “((policy, best path, etc., allowing)” doesn’t parse for me.
(Suresh Krishnan) No Objection
Warren Kumari No Objection
Comment (2019-08-07 for -35)
No email
send info
send info
Thank you for writing this.
(Mirja Kühlewind) No Objection
Comment (2019-07-30 for -33)
Some comment on use of normative language: 1) I know what the intention is here but this normative language is not used correctly (sec 4): "A BGP speaker MAY send Extended Messages to a peer only if the Extended Message Capability was advertised by both peers." This should be a MUST anyway (and moving the "only"): "A BGP speaker MUST only send Extended Messages to a peer if the Extended Message Capability was advertised by both peers." Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g. "A BGP speaker MUST NOT send Extended Messages to a peer if the Extended Message Capability was not advertised by both peers. A BGP speaker MAY send Extended Messages to a peer if the Extended Message Capability was advertised by both peers." 2) sec 4: "If a BGP message with a Length greater than 4,096 octets is received by a BGP listener who has not advertised the Extended Message Capability, the listener MUST treat this as a malformed message, and MUST generate a NOTIFICATION with the Error Subcode set to Bad Message Length (see [RFC4271] Sec 6.1)." If this is specified normatively in RFC4271, you should not use normative language here as well. I suggest s/MUST/will/ 3) sec 4: s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/ and s/it must be withdrawn from service/it MUST be withdrawn from service/ 4) sec 4 "In an iBGP mesh, if BGP Extended Messages are to be advertized, all peers MUST advertize the BGP Extended Message capability." Which action(s) should be taken if that is not the case?