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)
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)
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?

Barry Leiba No Objection

Alexey Melnikov No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection