Skip to main content

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