idnits 2.17.1 draft-ietf-idr-dynamic-cap-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Chen 3 Internet Draft Palo Alto Networks 4 Intended status: Standards Track S. Sangli 5 Expiration Date: April 20, 2022 Juniper Networks 6 October 19, 2021 8 Dynamic Capability for BGP-4 9 draft-ietf-idr-dynamic-cap-15.txt 11 Abstract 13 This document defines a new BGP capability termed "Dynamic 14 Capability", which would allow the dynamic update of capabilities 15 over an established BGP session. This capability would facilitate 16 non-disruptive capability changes by BGP speakers. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 20, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 Currently BGP capabilities [RFC5492] are only advertised in the OPEN 53 message during the session initialization. In order to enable a new 54 capability or remove an existing capability (such as an Address 55 Family support [RFC4760]), an established session needs to be reset, 56 which may disrupt other services running over the session. 58 This document defines a new BGP capability termed "Dynamic 59 Capability", which would allow the dynamic update of capabilities 60 over an established BGP session. This capability would facilitate 61 non-disruptive capability changes by BGP speakers. 63 1.1. Specification of Requirements 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. Dynamic Capability 71 The Dynamic Capability is a new BGP capability [RFC5492]. The 72 Capability Code for this capability is specified in the "IANA 73 Considerations" section of this document. The Capability Value field 74 consists of a list of capability codes (one-octet for each) that 75 specify the capabilities that MAY be revised dynamically by the 76 remote speaker. 78 By advertising the Dynamic Capability to a peer in the OPEN, a BGP 79 speaker conveys to the peer that the speaker is capable of receiving 80 and properly handling the CAPABILITY message (as defined in the next 81 Section) from the peer after the BGP session has been established. 83 3. Capability Message 85 The CAPABILITY Message is a new BGP message type with type code 6. 86 In addition to the fixed-size BGP header [RFC4271], the CAPABILITY 87 message contains one or more of the following tuples of capability 88 revisions: 90 +------------------------------+ 91 | Init/Ack (1 bit) | 92 +------------------------------+ 93 | Ack Request (1 bit) | 94 +------------------------------+ 95 | Reserved (5 bits) | 96 +------------------------------+ 97 | Action (1 bit) | 98 +------------------------------+ 99 | Sequence Number (4 octets) | 100 +------------------------------+ 101 | Capability Code (1 octet) | 102 +------------------------------+ 103 | Capability Length (2 octets) | 104 +------------------------------+ 105 | Capability Value (variable) | 106 +------------------------------+ 108 The Init/Ack bit indicates whether a capability revision is being 109 initiated (when set to 0), or being acknowledged (when set to 1). 111 The Ack Request bit indicates whether an acknowledgment is requested 112 (when set to 1), or not (when set to 0) for a capability revision 113 being initiated. 115 The Reserved bits should be set to zero by the sender and ignored by 116 the receiver. 118 The Action bit is 0 for advertising a capability, and 1 for removing 119 a capability. 121 The Sequence Number field can be used by a BGP speaker to match an 122 acknowledgment with a capability revision that the speaker initiated 123 previously. 125 Conceptually the triple is the same as the one defined in [RFC5492], and it 127 specifies a capability for which the "Action" shall be applied. 129 4. Operation 131 A BGP speaker that is willing to receive the CAPABILITY message (for 132 one or more capability codes) from its peer SHOULD use the BGP 133 Capabilities Advertisement [RFC5492] to advertise the Dynamic 134 Capability for these capability codes. 136 A BGP speaker MAY send to its peer a CAPABILITY message to initiate 137 revisions for one or more capability codes only if these capability 138 codes are listed in the Dynamic Capability of the OPEN message 139 received from its peer. 141 A CAPABILITY message MAY be received only in the Established state. 142 Receiving a CAPABILITY message in any other state is a Finite State 143 Machine Error as defined in [RFC4271]. A BGP speaker SHOULD reset the 144 HoldTimer upon receiving a CAPABILITY message from its peer. 146 When a BGP speaker sends a CAPABILITY message to its peer to initiate 147 a capability revision, the Init/Ack bit for the capability revision 148 in the message MUST be set to 0. The setting of the Ack Request bit 149 is capability specific. The assignment of the Sequence Number is a 150 local matter, but MUST allow the BGP speaker to unambiguously 151 identify a capability revision it initiated previously based on the 152 Sequence Number carried in the acknowledgment from the peer. 154 If the Init/Ack bit is set to 1 for a capability revision in a 155 CAPABILITY message received by a BGP speaker, then the BGP speaker 156 SHALL treat the capability revision as an acknowledgment of the 157 receipt of a capability revision initiated by the BGP speaker. The 158 BGP speaker MUST ignore the Ack Request bit, and SHALL use the 159 Sequence Number carried in the capability revision to match with the 160 capability revision previously initiated. The BGP speaker SHALL 161 ignore an acknowledgment for a capability revision in which an 162 acknowledgment was not requested by the BGP speaker. If the Sequence 163 Number carried in the capability revision does not match any of the 164 the Sequence Numbers used in the capability revisions initiated by 165 the BGP speaker, then the BGP speaker SHOULD send a NOTIFICATION 166 message as specified in the Error Handling section. 168 If the Init/Ack bit is set to 0 for a capability revision in a 169 CAPABILITY message received by a BGP speaker, then the BGP speaker 170 SHOULD first validate the capability code in the message. If the 171 capability code is not listed in the Dynamic Capability advertised by 172 the speaker to the peer, the BGP speaker SHOULD send a NOTIFICATION 173 message as specified in the Error Handling section. For a valid 174 capability code, if the Ack Request bit is set to 1, the BGP speaker 175 MUST first send a CAPABILITY message to acknowledge the receipt of 176 the capability revision. The Init/Ack bit in the acknowledgment MUST 177 be set to 1, and all the other fields in the capability revision MUST 178 be kept unchanged. 180 After receiving a capability revision initiated by a peer, the BGP 181 speaker SHALL update the capability previously received from that 182 peer based on the Action bit in the message, and then function in 183 accordance with the revised capability for the peer. The BGP speaker 184 SHALL ignore such a capbility revision that either results in no 185 change to an existing capability, or removes a capability that was 186 not advertised previously. The procedures specified in the "Error 187 Handling" section SHOULD be followed when an error is detected in 188 processing the CAPABILITY message. 190 In order to avoid ambiguities in sending and processing UPDATE 191 messages, certain capability revisions may require close coordination 192 between the BGP speaker (the Initiator) that initiates the capability 193 revisions and another BGP speaker (the Receiver) that receives the 194 capability revisions. The mechanism of acknowledgment defined in 195 this document SHALL be used for the revision of such a capability. 196 For the Initiator, the capability revision SHALL take effect (for the 197 purpose of sending updates) immediately after the capability revision 198 is sent, and the capability revision SHALL take effect (for the 199 purpose of receiving updates) immediately after an acknowledgment is 200 received from the Receiver. For the Receiver, the capability 201 revision SHALL take effect (for the purpose of receiving updates) 202 immediately after the capability revision is received from the 203 Initiator, and the capability revision SHALL take effect (for the 204 purpose of sending updates) immediately after an acknowledgment is 205 sent. 207 5. Error Handling 209 This document defines a new NOTIFICATION error code: 211 Error Code Symbolic Name 213 7 CAPABILITY Message Error 215 The following error subcodes are defined as well: 217 Subcode Symbolic Name 219 1 Unknown Sequence Number 220 2 Invalid Capability Length 221 3 Malformed Capability Value 222 4 Unsupported Capability Code 224 If a BGP speaker detects an error while processing a CAPABILITY 225 message, it MUST send a NOTIFICATION message with Error Code 226 CAPABILITY Message Error. If any of the defined error subcode is 227 applicable, the Data field of the NOTIFICATION message MUST contain 228 the tuple for the capability revision that causes the speaker to send 229 the message. 231 If the Sequence Number carried in a capability revision marked as 232 acknowledgment does not match any of the the Sequence Numbers used in 233 the capability revisions initiated by the BGP speaker, then the error 234 subcode is set to Unknown Sequence Number. 236 If the Capability Length field in the CAPABILITY message is incorrect 237 for a Capability Code, then the error subcode is set to Invalid 238 Capability Length. 240 If the Capability Value field in the CAPABILITY message is malformed 241 (the definition of "malformed" depends on the Capability Code), then 242 the error subcode is set to Malformed Capability Value. 244 If the Capability Code in the CAPABILITY message is not any of the 245 capability codes advertised in the Dynamic Capability by the speaker, 246 then the error subcode is set to Unsupported Capability Code. 248 6. IANA Considerations 250 This document defines the CAPABILITY message type for BGP with type 251 code 6, and a NOTIFICATION error code and subcodes for the errors in 252 a CAPABILITY message. 254 This document uses a BGP capability code to indicate that a BGP 255 speaker supports the Dynamic Capability. The capability code 67 has 256 been assigned by IANA. 258 7. Security Considerations 260 This extension to BGP does not change the underlying security issues. 262 8. Acknowledgments 264 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 265 Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno 266 Rijsman, John Scudder and Jeffrey Haas for their review and comments. 268 9. Normative References 270 [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway 271 Protocol 4 (BGP-4)," RFC 4271, January 2006. 273 [RFC4760] Bates, T., Chandra, R., Rekhter, Y., and D. Katz, 274 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 276 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 277 with BGP-4", RFC 5492, February 2009. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 10. Authors' Addresses 284 Enke Chen 285 Palo Alto Networks, Inc. 287 Email: enchen@paloaltonetworks.com 289 Srihari R. Sangli 290 Juniper Networks, Inc. 292 Email: ssangli@juniper.net