idnits 2.17.1 draft-ietf-idr-dynamic-cap-05.txt: ** The Abstract section seems to be numbered 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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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) == Unused Reference: 'RFC-2026' is defined on line 270, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-24 ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2385 (ref. 'BGP-MD5') (Obsoleted by RFC 5925) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Redback Networks 4 Expiration Date: January 2005 Srihari R. Sangli 5 Procket Networks 7 Dynamic Capability for BGP-4 9 draft-ietf-idr-dynamic-cap-05.txt 11 1. Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 except that the right to 20 produce derivative works is not granted. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 2. Abstract 40 This document defines a new BGP capability termed "Dynamic 41 Capability", which would allow the dynamic update of capabilities 42 over an established BGP session. This capability would facilitate 43 non-disruptive capability changes by BGP speakers. 45 3. Introduction 47 Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN 48 message during the session initialization. In order to enable a new 49 capability or remove an existing capability (such as an Address 50 Family support [BGP-MP]), an established session needs to be reset, 51 which may disrupt other services running over the session. 53 This document defines a new BGP capability termed "Dynamic 54 Capability", which would allow the dynamic update of capabilities 55 over an established BGP session. This capability would facilitate 56 non-disruptive capability changes by BGP speakers. 58 4. Specification of Requirements 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC-2119]. 64 5. Dynamic Capability 66 The Dynamic Capability is a new BGP capability [BGP-CAP]. The 67 Capability Code for this capability is specified in the "IANA 68 Considerations" section of this document. The Capability Length 69 field of this capability is one octet. The Capability Value field 70 consists of a list of capability codes (one-octet for each) for which 71 the dynamic revision is supported by a BGP speaker. 73 By advertising the Dynamic Capability to a peer in the OPEN, a BGP 74 speaker conveys to the peer that the speaker is capable of receiving 75 and properly handling the CAPABILITY message (as defined in the next 76 Section) from the peer after the BGP session has been established. 78 6. Capability Message 80 The CAPABILITY Message is a new BGP message type with type code 6. 81 In addition to the fixed-size BGP header [BGP-4], the CAPABILITY 82 message contains one or more of the following tuples of capability 83 revisions: 85 +------------------------------+ 86 | Init/Ack (1 bit) | 87 +------------------------------+ 88 | Ack Request (1 bit) | 89 +------------------------------+ 90 | Reserved (5 bits) | 91 +------------------------------+ 92 | Action (1 bit) | 93 +------------------------------+ 94 | Sequence Number (4 octets) | 95 +------------------------------+ 96 | Capability Code (1 octet) | 97 +------------------------------+ 98 | Capability Length (1 octet) | 99 +------------------------------+ 100 | Capability Value (variable) | 101 +------------------------------+ 103 The Init/Ack bit indicates whether a capability revision is being 104 initiated (when set to 0), or being acknowledged (when set to 1). 106 The Ack Request bit indicates whether an acknowledgement is requested 107 (when set to 1), or not (when set to 0) for a capability revision 108 being initiated. 110 The Reserved bits should be set to zero by the sender and ignored by 111 the receiver. 113 The Action bit is 0 for advertising a capability, and 1 for removing 114 a capability. 116 The Sequence Number field can be used by a BGP speaker to match an 117 acknowledgement with a capability revision that the speaker initiated 118 previously. 120 The triple is 121 the same as defined in [BGP-CAP], and it specifies a capability for 122 which the "Action" shall be applied. The triple is optional when the 123 Init/Ack bit is set to 1. 125 7. Operation 127 A BGP speaker that is willing to receive the CAPABILITY message (for 128 one or more capability codes) from its peer SHOULD use the BGP 129 Capabilities Advertisement [BGP-CAP] to advertise the Dynamic 130 Capability for these capability codes. 132 A BGP speaker MAY send to its peer a CAPABILITY message to initiate 133 revisions for one or more capability codes only if these capability 134 codes are listed in the Dynamic Capability of the OPEN message 135 received 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 8. 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 9. IANA Considerations 238 This document uses a BGP capability code to indicate that a BGP 239 speaker supports the Dynamic Capability. The capability code has 240 been assigned by IANA per RFC 2842. 242 10. Security Considerations 244 This extension to BGP does not change the underlying security issues 245 [BGP-MD5]. 247 11. Acknowledgments 249 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 250 Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno 251 Rijsman and John Scudder for their review and comments. 253 12. References 255 [BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 256 4 (BGP-4)", draft-ietf-idr-bgp4-24.txt, November 2003. 258 [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 259 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 261 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 262 BGP-4", RFC 2842, May 2000. 264 [BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 265 Signature Option", RFC 2385, August 1998. 267 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 271 3", RFC 2026, October 1996. 273 13. Author Information 275 Enke Chen 276 Redback Networks, Inc. 277 300 Holger Way 278 San Jose, CA 95134 279 e-mail: enke@redback.com 281 Srihari R. Sangli 282 Procket Networks, Inc. 283 1100 Cadillac Court 284 Milpitas, CA 95035 285 e-mail: srihari@procket.com 287 14. Intellectual Property Considerations 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at ietf- 309 ipr@ietf.org. 311 15. Full Copyright Notice 313 Copyright (C) The Internet Society (2004). This document is subject 314 to the rights, licenses and restrictions contained in BCP 78, and 315 except as set forth therein, the authors retain all their rights. 317 This document and the information contained herein is provided on an 318 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 319 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 320 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 321 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 322 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.