idnits 2.17.1 draft-ietf-idr-dynamic-cap-04.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 5 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 6 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '... message, it MUST send a NOTIFICATIO...' RFC 2119 keyword, line 140: '... the NOTIFICATION message MUST contain...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4BYTE-AS' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: February 2004 Srihari R. Sangli 5 Procket Networks 7 Dynamic Capability for BGP-4 9 draft-ietf-idr-dynamic-cap-04.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except that the right to 15 produce derivative works is not granted. 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 2. 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 3. 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 4. Dynamic Capability 55 The Dynamic Capability is a new BGP capability [BGP-CAP]. The 56 Capability Code for this capability is specified in the "IANA 57 Considerations" section of this document. The Capability Length 58 field of this capability is one octet. The Capability Value field 59 consists of a list of capability codes (one-octet for each) for which 60 the dynamic revision is supported by a BGP speaker. 62 By advertising the Dynamic Capability to a peer in the OPEN, a BGP 63 speaker conveys to the peer that the speaker is capable of receiving 64 and properly handling the CAPABILITY message (as defined in the next 65 Section) from the peer after the BGP session has been established. 67 5. Capability Message 69 The CAPABILITY Message is a new BGP message type with type code 6. 70 In addition to the fixed-size BGP header [BGP-4], the CAPABILITY 71 message contains one or more of the following tuples: 73 +------------------------------+ 74 | Action (1 octet) | 75 +------------------------------+ 76 | Capability Code (1 octet) | 77 +------------------------------+ 78 | Capability Length (1 octet) | 79 +------------------------------+ 80 | Capability Value (variable) | 81 +------------------------------+ 83 The value of the Action field is 0 for advertising a capability, and 84 1 for removing a capability. 86 The triple is 87 the same as defined in [BGP-CAP], and it specifies a capability for 88 which the "Action" shall be applied. 90 6. Operation 92 A BGP speaker that is willing to receive the CAPABILITY message (for 93 one or more capability codes) from its peer should use BGP 94 Capabilities Advertisement [BGP-CAP] to advertise the Dynamic 95 Capability for these capability codes. 97 A BGP speaker may send to its peer a CAPABILITY message that contains 98 one or more capability codes only if these capability codes are 99 listed in the Dynamic Capability of the OPEN message received from 100 its peer. 102 Upon receiving a CAPABILITY message from its peer, if a capability 103 code in the message is listed in the Dynamic Capability advertised by 104 the speaker to the peer, the BGP speaker shall update the capability 105 previously received from that peer based on the "Action" in the 106 message, and then function in accordance with the revised capability 107 for the peer. The procedures specified in the "Error Handling" 108 section should be followed when an error is detected in processing 109 the CAPABILITY message. 111 The Dynamic Capability itself can not be revised dynamically via a 112 CAPABILITY message. The lifetime of the Dynamic Capability is the 113 duration of the BGP session in which the capability is advertised. 115 It is also noted that the dynamic capability revision may not be 116 feasible and should be disallowed for some capabilities. One example 117 is the four-byte AS number capability [BGP-4BYTE-AS] as its dynamic 118 update could introduce ambiguity in parsing the UPDATE messages. 120 7. Error Handling 122 This document defines a new NOTIFICATION error code: 124 Error Code Symbolic Name 126 7 CAPABILITY Message Error 128 The following error subcodes are defined as well: 130 Subcode Symbolic Name 132 1 Invalid Action Value 133 2 Invalid Capability Length 134 3 Malformed Capability Value 135 4 Unsupported Capability Code 137 If a BGP speaker detects an error while processing a CAPABILITY 138 message, it MUST send a NOTIFICATION message with Error Code 139 CAPABILITY Message Error. If any of the defined error subcode is 140 applicable, the Data field of the NOTIFICATION message MUST contain 141 the erroneous tuple that causes the speaker to send the message. 144 If the Action field in the CAPABILITY message is other than 0 or 1, 145 then the error subcode is set to Invalid Action Value. 147 If the Capability Length field in the CAPABILITY message is incorrect 148 for a Capability Code, then the error subcode is set to Invalid 149 Capability Length. 151 If the Capability Value field in the CAPABILITY message is malformed 152 (the definition of "malformed" depends on the Capability Code), then 153 the error subcode is set to Malformed Capability Value. 155 If the Capability Code in the CAPABILITY message is not any of the 156 capability codes advertised in the Dynamic Capability by the speaker, 157 then the error subcode is set to Unsupported Capability Code. 159 8. IANA Considerations 161 This document uses a BGP capability code to indicate that a BGP 162 speaker supports the Dynamic Capability. The capability code has 163 been assigned by IANA per RFC 2842. 165 9. Intellectual Property Considerations 167 This section is taken from Section 10.4 of [RFC-2026]. 169 The IETF takes no position regarding the validity or scope of any 170 intellectual property or other rights that might be claimed to 171 pertain to the implementation or use of the technology described in 172 this document or the extent to which any license under such rights 173 might or might not be available; neither does it represent that it 174 has made any effort to identify any such rights. Information on the 175 IETF's procedures with respect to rights in standards-track and 176 standards-related documentation can be found in BCP-11. Copies of 177 claims of rights made available for publication and any assurances of 178 licenses to be made available, or the result of an attempt made to 179 obtain a general license or permission for the use of such 180 proprietary rights by implementors or users of this specification can 181 be obtained from the IETF Secretariat. 183 The IETF invites any interested party to bring to its attention any 184 copyrights, patents or patent applications, or other proprietary 185 rights which may cover technology that may be required to practice 186 this standard. Please address the information to the IETF Executive 187 Director. 189 The IETF has been notified of intellectual property rights claimed in 190 regard to some or all of the specification contained in this 191 document. For more information consult the online list of claimed 192 rights. 194 10. Security Considerations 196 This extension to BGP does not change the underlying security issues. 198 11. Acknowledgments 200 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 201 Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno 202 Rijsman and John Scudder for their review and comments. 204 12. References 206 [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 207 RFC 1771, March 1995. 209 [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 210 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 212 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 213 BGP-4", RFC 2842, May 2000. 215 [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS 216 number space", Work in Progress, , 217 September 2001. 219 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 220 3", RFC 2026, October 1996. 222 13. Author Information 224 Enke Chen 225 Redback Networks, Inc. 226 350 Holger Way 227 San Jose, CA 95134 228 e-mail: enke@redback.com 230 Srihari R. Sangli 231 Procket Networks, Inc. 232 1100 Cadillac Court 233 Milpitas, CA 95035 234 e-mail: srihari@procket.com