draft-ietf-idr-bgp-extended-messages-29.txt   draft-ietf-idr-bgp-extended-messages-30.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Updates: 4271 (if approved) K. Patel Updates: 4271 (if approved) K. Patel
Intended status: Standards Track Arrcus, Inc. Intended status: Standards Track Arrcus, Inc.
Expires: September 11, 2019 D. Ward Expires: September 27, 2019 D. Ward
Cisco Systems Cisco Systems
March 10, 2019 March 26, 2019
Extended Message support for BGP Extended Message support for BGP
draft-ietf-idr-bgp-extended-messages-29 draft-ietf-idr-bgp-extended-messages-30
Abstract Abstract
The BGP specification mandates a maximum BGP message size of 4096 The BGP specification mandates a maximum BGP message size of 4096
octets. As BGP is extended to support newer AFI/SAFIs and other octets. As BGP is extended to support newer AFI/SAFIs and other
features, there is a need to extend the maximum message size beyond features, there is a need to extend the maximum message size beyond
4096 octets. This document updates the BGP specification RFC4271 by 4096 octets. This document updates the BGP specification RFC4271 by
providing an extension to BGP to extend its current maximum message providing an extension to BGP to extend its current maximum message
size from 4096 octets to 65535 octets for all except the OPEN size from 4096 octets to 65535 octets for all except the OPEN
message. message.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2019. This Internet-Draft will expire on September 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 5 skipping to change at page 4, line 5
A BGP announcement will, in the normal case, propagate throughout the A BGP announcement will, in the normal case, propagate throughout the
BGP speaking Internet; and there will undoubtedly be BGP speakers BGP speaking Internet; and there will undoubtedly be BGP speakers
which do not have the Extended Message capability. Therefore, having which do not have the Extended Message capability. Therefore, having
an attribute set which can not be decomposed to 4096 octets or less an attribute set which can not be decomposed to 4096 octets or less
in an Extended Message will likely raise errors. in an Extended Message will likely raise errors.
A BGP speaker with a mixture of peers some of which have negotiated A BGP speaker with a mixture of peers some of which have negotiated
BGP Extended Message capability and some which have not, MUST BGP Extended Message capability and some which have not, MUST
o support [RFC7606], and o support [RFC7606], and
o "treat as withdraw' (see [RFC7606]) a BGP attribue/NLRI pair which o "treat as withdraw" (see [RFC7606]) a BGP attribute/NLRI pair
is too large to be sent to a peer which does not support BGP (defined as BGP Route) which is too large to be sent to a peer
Extended Messages. which does not support BGP Extended Messages.
The BGP speaker MAY remove some BGP attributes which are eligible to The BGP speaker MAY remove some BGP attributes which are eligible to
use the Attribute discard approach in [RFC7606]. use the Attribute discard approach in [RFC7606].
In an iBGP mesh, all peers SHOULD support the BGP Extended Message In an iBGP mesh, all peers SHOULD support the BGP Extended Message
Capability and [RFC7606]. Only then is it consistent to deploy with Capability and [RFC7606]. Only then is it consistent to deploy with
eBGP peers. eBGP peers.
During the incremental deployment of BGP Extended Messages and During the incremental deployment of BGP Extended Messages and
[RFC7606] in an iBGP mesh, or with eBGP peers, the operator should [RFC7606] in an iBGP mesh, or with eBGP peers, the operator should
skipping to change at page 5, line 7 skipping to change at page 5, line 7
relevant information as reasonably possible. relevant information as reasonably possible.
6. Changes to RFC4271 6. Changes to RFC4271
[RFC4271] states "The value of the Length field MUST always be at [RFC4271] states "The value of the Length field MUST always be at
least 19 and no greater than 4096." This document changes the latter least 19 and no greater than 4096." This document changes the latter
number to 65535 for all except the OPEN message. number to 65535 for all except the OPEN message.
[RFC4271] Sec 6.1, specifies raising an error if the length of a [RFC4271] Sec 6.1, specifies raising an error if the length of a
message is over 4096 octets. For all messages except the OPEN message is over 4096 octets. For all messages except the OPEN
message, if the receiver has advertised the capability to receive message, if the receiver has advertised the BGP Extended Messages
Extended Messages, this document raises that limit to 65535. Capability, this document raises that limit to 65535.
7. IANA Considerations 7. IANA Considerations
The IANA has made an early allocation for this new BGP Extended The IANA has made an early allocation for this new BGP Extended
Message Capability referring to this document. Message Capability referring to this document.
Registry: BGP Capability Code Registry: BGP Capability Code
Value Description Document Value Description Document
----- ----------------------------------- ------------- ----- ----------------------------------- -------------
skipping to change at page 5, line 51 skipping to change at page 5, line 51
If a remote attacker is able to craft a large BGP Extended Message to If a remote attacker is able to craft a large BGP Extended Message to
send on a path where one or more peers do not support BGP Extended send on a path where one or more peers do not support BGP Extended
Messages, peers which support BGP Extended Messages may incur Messages, peers which support BGP Extended Messages may incur
resource load (processing, message resizing, etc.) reformatting the resource load (processing, message resizing, etc.) reformatting the
large messages. Worse, ([RFC7606] "treat as withdraw" may large messages. Worse, ([RFC7606] "treat as withdraw" may
consistently withdraw announcements causing inconsistent routing. consistently withdraw announcements causing inconsistent routing.
BGP routes are filtered by policies set by the operators. BGP routes are filtered by policies set by the operators.
Implementations may provide policies to filter routes that would Implementations may provide policies to filter routes that would
cause the "treat as withdraw" from being pass by an extended message cause the "treat as withdraw" from being passed by an extended
speaker. message speaker.
9. Acknowledgments 9. Acknowledgments
The authors thank Alvaro Retana, Enke Chen, Susan Hares, John The authors thank Alvaro Retana, Enke Chen, Susan Hares, John
Scudder, John Levine, and Job Snijders for their input; and Oliver Scudder, John Levine, and Job Snijders for their input; and Oliver
Borchert and Kyehwan Lee for their implementations and testing. Borchert and Kyehwan Lee for their implementations and testing.
10. References 10. References
10.1. Normative References 10.1. Normative References
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/