Extended Message Support for BGP
draft-ietf-idr-bgp-extended-messages-36
Yes
(Alvaro Retana)
No Objection
Éric Vyncke
(Alexey Melnikov)
(Barry Leiba)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 33 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-08-07 for -35)
Not sent
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.
Warren Kumari
No Objection
Comment
(2019-08-07 for -35)
Not sent
Thank you for writing this.
Éric Vyncke
No Objection
Alvaro Retana Former IESG member
Yes
Yes
(for -33)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -33)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2019-08-06 for -35)
Sent
'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).
Barry Leiba Former IESG member
No Objection
No Objection
(for -35)
Not sent
Deborah Brungard Former IESG member
No Objection
No Objection
(for -35)
Not sent
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -35)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -35)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2019-07-30 for -33)
Sent
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?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -35)
Not sent