idnits 2.17.1 draft-ietf-idr-dynamic-cap-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 308. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 8 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft S. Sangli 4 Expiration Date: May 2007 Cisco Systems 6 Dynamic Capability for BGP-4 8 draft-ietf-idr-dynamic-cap-09.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines a new BGP capability termed "Dynamic 36 Capability", which would allow the dynamic update of capabilities 37 over an established BGP session. This capability would facilitate 38 non-disruptive capability changes by BGP speakers. 40 1. Introduction 42 Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN 43 message during the session initialization. In order to enable a new 44 capability or remove an existing capability (such as an Address 45 Family support [BGP-MP]), an established session needs to be reset, 46 which may disrupt other services running over the session. 48 This document defines a new BGP capability termed "Dynamic 49 Capability", which would allow the dynamic update of capabilities 50 over an established BGP session. This capability would facilitate 51 non-disruptive capability changes by BGP speakers. 53 2. Specification of Requirements 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC-2119]. 59 3. Dynamic Capability 61 The Dynamic Capability is a new BGP capability [BGP-CAP]. The 62 Capability Code for this capability is specified in the "IANA 63 Considerations" section of this document. The Capability Value field 64 consists of a list of capability codes (one-octet for each) that 65 specify the capabilities that MAY be revised dynamically by the 66 remote speaker. 68 By advertising the Dynamic Capability to a peer in the OPEN, a BGP 69 speaker conveys to the peer that the speaker is capable of receiving 70 and properly handling the CAPABILITY message (as defined in the next 71 Section) from the peer after the BGP session has been established. 73 4. Capability Message 75 The CAPABILITY Message is a new BGP message type with type code 6. 76 In addition to the fixed-size BGP header [BGP-4], the CAPABILITY 77 message contains one or more of the following tuples of capability 78 revisions: 80 +------------------------------+ 81 | Init/Ack (1 bit) | 82 +------------------------------+ 83 | Ack Request (1 bit) | 84 +------------------------------+ 85 | Reserved (5 bits) | 86 +------------------------------+ 87 | Action (1 bit) | 88 +------------------------------+ 89 | Sequence Number (4 octets) | 90 +------------------------------+ 91 | Capability Code (1 octet) | 92 +------------------------------+ 93 | Capability Length (2 octets) | 94 +------------------------------+ 95 | Capability Value (variable) | 96 +------------------------------+ 98 The Init/Ack bit indicates whether a capability revision is being 99 initiated (when set to 0), or being acknowledged (when set to 1). 101 The Ack Request bit indicates whether an acknowledgement is requested 102 (when set to 1), or not (when set to 0) for a capability revision 103 being initiated. 105 The Reserved bits should be set to zero by the sender and ignored by 106 the receiver. 108 The Action bit is 0 for advertising a capability, and 1 for removing 109 a capability. 111 The Sequence Number field can be used by a BGP speaker to match an 112 acknowledgement with a capability revision that the speaker initiated 113 previously. 115 Conceptually the triple is the same as the one defined in [BGP-CAP], and it 117 specifies a capability for which the "Action" shall be applied. The 118 triple is optional when the Init/Ack bit is set to 1. 120 5. Operation 122 A BGP speaker that is willing to receive the CAPABILITY message (for 123 one or more capability codes) from its peer SHOULD use the BGP 124 Capabilities Advertisement [BGP-CAP] to advertise the Dynamic 125 Capability for these capability codes. 127 A BGP speaker MAY send to its peer a CAPABILITY message to initiate 128 revisions for one or more capability codes only if these capability 129 codes are listed in the Dynamic Capability of the OPEN message 130 received from its peer. 132 A CAPABILITY message MAY be received only in the Established state. 133 Receiving a CAPABILITY message in any other state is a Finite State 134 Machine Error as defined in [BGP-4]. A BGP speaker SHOULD reset the 135 HoldTimer upon receiving a CAPABILITY message from its peer. 137 When a BGP speaker sends a CAPABILITY message to its peer to initiate 138 a capability revision, the Init/Ack bit for the capability revision 139 in the message MUST be set to 0. The setting of the Ack Request bit 140 is capability specific. The assignment of the Sequence Number is a 141 local matter, but MUST allow the BGP speaker to unambiguously 142 identify a capability revision it initiated previously based on the 143 Sequence Number carried in the acknowledgement from the peer. 145 If the Init/Ack bit is set to 1 for a capability revision in a 146 CAPABILITY message received by a BGP speaker, then the BGP speaker 147 SHALL treat the capability revision as an acknowledgement of the 148 receipt of a capability revision initiated by the BGP speaker. The 149 BGP speaker MUST ignore the Ack Request bit, and SHALL use the 150 Sequence Number carried in the capability revision to match with the 151 capability revision previously initiated. The BGP speaker SHALL 152 ignore an acknowledgement for a capability revision in which an 153 acknowledgement was not requested by the BGP speaker. If the 154 Sequence Number carried in the capability revision does not match any 155 of the the Sequence Numbers used in the capability revisions 156 initiated by the BGP speaker, then the BGP speaker SHOULD send a 157 NOTIFICATION message as specified in the Error Handling section. 159 If the Init/Ack bit is set to 0 for a capability revision in a 160 CAPABILITY message received by a BGP speaker, then the BGP speaker 161 SHOULD first validate the capability code in the message. If the 162 capability code is not listed in the Dynamic Capability advertised by 163 the speaker to the peer, the BGP speaker SHOULD send a NOTIFICATION 164 message as specified in the Error Handling section. For a valid 165 capability code, if the Ack Request bit is set to 1, the BGP speaker 166 MUST first send a CAPABILITY message to acknowledge the receipt of 167 the capability revision. The Init/Ack bit in the acknowledgement 168 MUST be set to 1, and all the other fields in the capability revision 169 MUST be kept unchanged except that the triple MAY be optionally excluded. 172 After receiving a capability revision initiated by a peer, the BGP 173 speaker SHALL update the capability previously received from that 174 peer based on the Action bit in the message, and then function in 175 accordance with the revised capability for the peer. The procedures 176 specified in the "Error Handling" section SHOULD be followed when an 177 error is detected in processing the CAPABILITY message. 179 In order to avoid ambiguities in sending and processing UPDATE 180 messages, certain capability revisions may require close coordination 181 between the BGP speaker (the Initiator) that initiates the capability 182 revisions and another BGP speaker (the Receiver) that receives the 183 capability revisions. The mechanism of acknowledgement defined in 184 this document SHALL be used for the revision of such a capability. 185 For the Initiator, the capability revision SHALL take effect (for 186 sending updates) immediately after the capability revision is sent, 187 and the capability revision SHALL take effect (for receiving updates) 188 immediately after an acknowledgement is received from the Receiver. 189 For the Receiver, the capability revision SHALL take effect (for 190 receiving updates) immediately after the capability revision is 191 received from the Initiator, and the capability revision SHALL take 192 effect (for sending updates) immediately after an acknowledgement is 193 sent. 195 6. Error Handling 197 This document defines a new NOTIFICATION error code: 199 Error Code Symbolic Name 201 7 CAPABILITY Message Error 203 The following error subcodes are defined as well: 205 Subcode Symbolic Name 207 1 Unknown Sequence Number 208 2 Invalid Capability Length 209 3 Malformed Capability Value 210 4 Unsupported Capability Code 212 If a BGP speaker detects an error while processing a CAPABILITY 213 message, it MUST send a NOTIFICATION message with Error Code 214 CAPABILITY Message Error. If any of the defined error subcode is 215 applicable, the Data field of the NOTIFICATION message MUST contain 216 the tuple for the capability revision that causes the speaker to send 217 the message. 219 If the Sequence Number carried in a capability revision marked as 220 acknowledgement does not match any of the the Sequence Numbers used 221 in the capability revisions initiated by the BGP speaker, then the 222 error subcode is set to Unknown Sequence Number. 224 If the Capability Length field in the CAPABILITY message is incorrect 225 for a Capability Code, then the error subcode is set to Invalid 226 Capability Length. 228 If the Capability Value field in the CAPABILITY message is malformed 229 (the definition of "malformed" depends on the Capability Code), then 230 the error subcode is set to Malformed Capability Value. 232 If the Capability Code in the CAPABILITY message is not any of the 233 capability codes advertised in the Dynamic Capability by the speaker, 234 then the error subcode is set to Unsupported Capability Code. 236 7. IANA Considerations 238 This document defines the CAPABILITY message type for BGP with type 239 code 6, and a NOTIFICATION error code and subcodes for the errors in 240 a CAPABILITY message. 242 This document uses a BGP capability code to indicate that a BGP 243 speaker supports the Dynamic Capability. The capability code needs 244 to be assigned by IANA per RFC 2842. 246 8. Security Considerations 248 This extension to BGP does not change the underlying security issues. 250 9. Acknowledgments 252 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 253 Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno 254 Rijsman and John Scudder for their review and comments. 256 10. Normative References 258 [BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 259 4 (BGP-4)", RFC 4271, January 2006. 261 [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 262 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 264 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 265 BGP-4", RFC 2842, May 2000. 267 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 11. Author Information 272 Enke Chen 273 Cisco Systems, Inc. 274 170 W. Tasman Dr. 275 San Jose, CA 95134 277 Email: enkechen@cisco.com 279 Srihari R. Sangli 280 Cisco Systems, Inc. 281 170 W. Tasman Dr. 282 San Jose, CA 95134 284 Email: rsrihari@cisco.com 286 12. Intellectual Property Considerations 288 The IETF takes no position regarding the validity or scope of any 289 Intellectual Property Rights or other rights that might be claimed to 290 pertain to the implementation or use of the technology described in 291 this document or the extent to which any license under such rights 292 might or might not be available; nor does it represent that it has 293 made any independent effort to identify any such rights. Information 294 on the procedures with respect to rights in RFC documents can be 295 found in BCP 78 and BCP 79. 297 Copies of IPR disclosures made to the IETF Secretariat and any 298 assurances of licenses to be made available, or the result of an 299 attempt made to obtain a general license or permission for the use of 300 such proprietary rights by implementers or users of this 301 specification can be obtained from the IETF on-line IPR repository at 302 http://www.ietf.org/ipr. 304 The IETF invites any interested party to bring to its attention any 305 copyrights, patents or patent applications, or other proprietary 306 rights that may cover technology that may be required to implement 307 this standard. Please address the information to the IETF at ietf- 308 ipr@ietf.org. 310 13. Full Copyright Notice 312 Copyright (C) The IETF Trust (2006). 314 This document is subject to the rights, licenses and restrictions 315 contained in BCP 78, and except as set forth therein, the authors 316 retain all their rights. 318 This document and the information contained herein are provided on an 319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.