--- 1/draft-ietf-idr-bgp-extended-messages-21.txt 2017-08-15 12:13:07.171712133 -0700 +++ 2/draft-ietf-idr-bgp-extended-messages-22.txt 2017-08-15 12:13:07.187712518 -0700 @@ -1,30 +1,31 @@ Network Working Group R. Bush Internet-Draft Internet Initiative Japan Updates: 4271 (if approved) K. Patel Intended status: Standards Track Arrcus, Inc. -Expires: September 6, 2017 D. Ward +Expires: February 16, 2018 D. Ward Cisco Systems - March 5, 2017 + August 15, 2017 Extended Message support for BGP - draft-ietf-idr-bgp-extended-messages-21 + draft-ietf-idr-bgp-extended-messages-22 Abstract The BGP specification mandates a maximum BGP message size of 4096 - octets. As BGP is extended to support newer AFI/SAFIs, there is a - need to extend the maximum message size beyond 4096 octets. This - document updates the BGP specification RFC4271 by providing an - extension to BGP to extend its current maximum message size from 4096 - octets to 65535 octets. + octets. As BGP is extended to support newer AFI/SAFIs and other + features, there is a need to extend the maximum message size beyond + 4096 octets. This document updates the BGP specification RFC4271 by + providing an extension to BGP to extend its current maximum message + size from 4096 octets to 65535 octets for all except the OPEN + message. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning. Status of This Memo @@ -35,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 6, 2017. + This Internet-Draft will expire on February 16, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -75,21 +76,22 @@ 10.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The BGP specification [RFC4271] mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size - limit from 4096 octets to 65535 octets. + limit from 4096 octets to 65535 octetsfor all except the OPEN + message. 2. BGP Extended Message A BGP message over 4096 octets in length is a BGP Extended Message. BGP Extended Messages have maximum message size of 65535 octets. The smallest message that may be sent consists of a BGP header without a data portion (19 octets). Multi-octet fields MUST be in network byte order. @@ -109,36 +111,37 @@ defined with Capability code 6 and Capability length 0. 4. Operation A BGP speaker that is willing to send and receive BGP Extended Messages with a peer SHOULD advertise the BGP Extended Message Capability to the peer using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY send Extended Messages to its peer only if it has received the Extended Message Capability from that peer. - Currently, the Extended Message Capability only applies to UPDATE - messages. + The Extended Message Capability only applies to all messages except + for the OPEN message. This exception is reduce compexity of + providing backward compatibility An implementation that advertises support for BGP Extended Messages - MUST be capable of receiving an UPDATE message with a length up to - and including 65535 octets. + MUST be capable of receiving a message with a length up to and + including 65535 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. A BGP announcement will, in the normal case, propagate throughout the BGP speaking Internet; and there will undoubtedly be BGP speakers which do not have the Extended Message capability. Therefore putting an attribute which can not be decomposed to 4096 octets or less in an - Extended Message is a sure path to routing failure. + Extended Message is a likely path to routing failure. 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, SHOULD NOT accept an Extended Message. A speaker MAY implement a more liberal policy and accept Extended Messages, even from a peer to which it has not advertised the capability, in the interest of preserving the BGP session if at all possible. @@ -151,26 +154,26 @@ The inconsistency between the local and remote BGP speakers MUST be flagged to the network operator through standard operational interfaces. The information should include the NLRI and as much relevant information as reasonably possible. 6. Changes to RFC4271 [RFC4271] states "The value of the Length field MUST always be at least 19 and no greater than 4096." This document changes the latter - number to 65535 for UPDATE messages. + number to 65535 for all except the OPEN message. [RFC4271] Sec 6.1, specifies raising an error if the length of a - message is over 4096 octets. For UPDATE messages, if the receiver - has advertised the capability to receive Extended Messages, this - document raises that limit to 65535. + message is over 4096 octets. For all messages except the OPEN + message, if the receiver has advertised the capability to receive + Extended Messages, this document raises that limit to 65535. 7. IANA Considerations The IANA has made an early allocation for this new BGP BGP Extended Message Capability referring to this document. Registry: BGP Capability Code Value Description Document ----- ----------------------------------- ------------- @@ -192,30 +195,36 @@ The authors thank Alvaro Retana, Enke Chen, Susan Hares, John Scudder, John Levine, and Job Snijders for their input; and Oliver Borchert and Kyehwan Lee for their implementations and testing. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . - [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway - Protocol 4 (BGP-4)", RFC 4271, January 2006. + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + . [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", - RFC 4272, January 2006. + RFC 4272, DOI 10.17487/RFC4272, January 2006, + . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement - with BGP-4", RFC 5492, February 2009. + with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February + 2009, . 10.2. Informative References [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- sidr-bgpsec-protocol-07 (work in progress), February 2013. Authors' Addresses Randy Bush