--- 1/draft-ietf-idr-bgp-extended-messages-32.txt 2019-07-02 11:13:10.064423513 -0700 +++ 2/draft-ietf-idr-bgp-extended-messages-33.txt 2019-07-02 11:13:10.084424019 -0700 @@ -1,21 +1,21 @@ Network Working Group R. Bush Internet-Draft IIJ & Arrcus Updates: 4271 (if approved) K. Patel Intended status: Standards Track Arrcus, Inc. Expires: January 3, 2020 D. Ward Cisco Systems July 2, 2019 Extended Message support for BGP - draft-ietf-idr-bgp-extended-messages-32 + draft-ietf-idr-bgp-extended-messages-33 Abstract The BGP specification mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support newer AFI/SAFIs and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification RFC4271 by extending the maximum message size from 4,096 octets to 65,535 octets for all except the OPEN and KEEPALIVE messages. @@ -66,21 +66,21 @@ 3. Extended Message Capability for BGP . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 6. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The BGP specification [RFC4271] mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., BGPsec [RFC8205] and BGP-LS [RFC7752]), there is a need to extend the maximum message size beyond 4,096 octets. This draft provides an extension to BGP to extend its message size limit from 4,096 octets to 65,535 octets for all except the OPEN and KEEPALIVE messages. @@ -107,98 +107,91 @@ A peer which does not advertise this capability MUST NOT send BGP Extended Messages, and BGP Extended Messages MUST NOT be sent to it. Peers that wish to use the BGP Extended Message capability MUST support Error Handling for BGP UPDATE Messages per [RFC7606]. 4. Operation The Extended Message Capability applies to all messages except for the OPEN and KEEPALIVE messages. The former exception is to reduce - the complexity of providing a backward compatibility. + the complexity of providing backward compatibility. A BGP speaker that is capable of sending and receiving BGP Extended Messages SHOULD advertise the BGP Extended Message Capability to its peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY send Extended Messages to a peer only if the Extended Message Capability was advertised by both peers. 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 which 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 lgreater than 4,096 octets is received + 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). - A BGP announcement will (policy, best path, etc., allowing) propagate - throughout the BGP speaking Internet; and hence to BGP speakers which - may not have the Extended Message capability. Therefore, an + A BGP UPDATE will (policy, best path, etc., allowing) typically + propagate throughout the BGP speaking Internet; and hence to BGP + speakers which may not support Extended Messages. Therefore, an announcement in an Extended Message where the size of the attribute - set plus the NLRI can not be decomposed to 4,096 octets or less may - cause lack of reachability. - - A BGP UPDATE will typically propagate throughout the BGP speaking - Internet; and hence to BGP speakers which may not support Extended - Messages. Therefore, a route announcement in an Extended Message - where the size of the attribute set plus the NLRI is larger than - 4,096 octets or less may cause lack of reachability. + set plus the NLRI is larger than 4,096 octets may cause lack of + reachability. A BGP speaker with a mixture of peers some of which have advertised the BGP Extended Message capability and some which have not, may receive an UPDATE from one of its capable peers that produces an ongoing announcement that is larger than 4,096 octets. When propagating that UPDATE onward to a neighbor which has not advertised the BGP Extended Message capability, the sender SHOULD try to reduce the outgoing message size by removing attributes eligible under the "attribute discard" approach of [RFC7606]. If the message is still - too big, then it MUST NOT be sent to the neighbor ([RFC4271], + too big, then it must NOT be sent to the neighbor ([RFC4271], Section 9.2). Additionally, if the NLRI was previously advertised to - that peer, it SHOULD be withdrawn from service ([RFC4271], + that peer, it must be withdrawn from service ([RFC4271], Section 9.1.3). In an iBGP mesh, if BGP Extended Messages are to be advertized, all - peers MUST advertize the BGP Extended Message Capability and - [RFC7606]. This is not only for consistent internal routing, but - also to give a consistent view to eBGP peers. + peers MUST advertize the BGP Extended Message capability. This is + not only for consistent internal routing, but also to give a + consistent view to eBGP peers. During the incremental deployment of BGP Extended Messages and [RFC7606] in an iBGP mesh, or with eBGP peers, the operator should - monitor any routes dropped as "treat-as-withdraw" and any discarded - attributes. - - It is RECOMMENDED that BGP protocol developers and implementers are - conservative in their application and use of Extended Messages. - Future protocol specifications MUST describe how to handle peers - which can only accommodate 4,096 octet messages. + monitor any routes dropped and any discarded attributes. 5. Error Handling A BGP speaker that has the ability to use Extended Messages but has not advertised the BGP Extended Messages capability, presumably due to configuration, MUST NOT accept an Extended Message. A speaker MUST NOT implement a more liberal policy accepting BGP Extended Messages. A BGP speaker that does not advertise the BGP Extended Messages capability might also genuinely not support Extended Messages. Such a speaker will follow the error handling procedures of [RFC4271] if it receives an Extended Message. Similarly, any speaker that treats an improper Extended Message as a fatal error, MUST follow the error handling procedures of [RFC4271]. + It is RECOMMENDED that BGP protocol developers and implementers are + conservative in their application and use of Extended Messages. + Future protocol specifications MUST describe how to handle peers + which can only accommodate 4,096 octet messages. + 6. Changes to RFC4271 [RFC4271] states "The value of the Length field MUST always be at least 19 and no greater than 4,096." This document changes the latter number to 65,535 for all except the OPEN and KEEPALIVE messages. [RFC4271] Sec 6.1, specifies raising an error if the length of a message is over 4,096 octets. For all messages except the OPEN message, if the receiver has advertised the BGP Extended Messages