The BGP Extended Message Capability applies to all messages except for OPEN and KEEPALIVE messages. These exceptions reduce the complexity of providing backward compatibility.
A BGP speaker that is capable of receiving BGP Extended Messages SHOULD
advertise the BGP Extended Message Capability to its peers using BGP Capabilities Advertisement [RFC 5492
]. A BGP speaker MAY
send BGP Extended Messages to a peer only if the BGP Extended Message Capability was received from that peer.
An implementation that advertises the BGP Extended Message Capability MUST
be capable of receiving a message with a length up to and including 65,535 octets.
Applications generating information that might be encapsulated within BGP messages MUST
limit the size of their payload to take the maximum message size into account.
If a BGP message with a length greater than 4,096 octets is received by a BGP listener who has not advertised the BGP Extended Message Capability, the listener will generate a NOTIFICATION with the Error Subcode set to Bad Message Length (RFC 4271
, Section 6.1
A BGP UPDATE will (if allowed by policy, best path, etc.) typically propagate throughout the BGP-speaking Internet and hence to BGP speakers that may not support BGP Extended Messages. Therefore, an announcement in a BGP Extended Message where the size of the attribute set plus the NLRI is larger than 4,096 octets may cause lack of reachability.
A BGP speaker that has advertised the BGP Extended Message Capability to its peers may receive an UPDATE from one of its peers that produces an ongoing announcement that is larger than 4,096 octets. When propagating that UPDATE onward to a neighbor that 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 [RFC 7606
]. If the message is still too big, then it must not be sent to the neighbor (RFC 4271
, Section 9.2
). Additionally, if the NLRI was previously advertised to that peer, it must be withdrawn from service (RFC 4271
, Section 9.1.3
If an Autonomous System (AS) has multiple internal BGP speakers and also has multiple external BGP neighbors, care must be taken to ensure a consistent view within the AS in order to present a consistent external view. In the context of BGP Extended Messages, a consistent view can only be guaranteed if all the Internal BGP (iBGP) speakers advertise the BGP Extended Message Capability. If that is not the case, then the operator should consider whether or not the BGP Extended Message Capability should be advertised to external peers.
During the incremental deployment of BGP Extended Messages and use of the "attribute discard" approach of [RFC 7606
] in an iBGP mesh or with External BGP (eBGP) peers, the operator should monitor any routes dropped and any discarded attributes.