idnits 2.17.1 draft-ietf-idr-dynamic-cap-02.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 4 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 5 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 102: '... Action Value" MUST be sent and the ...' RFC 2119 keyword, line 103: '... message MUST contain the erroneous ...' RFC 2119 keyword, line 107: '...pability Length" MUST be sent and the ...' RFC 2119 keyword, line 108: '...FICATION message MUST contain the Capa...' RFC 2119 keyword, line 114: '...apability Value" MUST be sent and the ...' (1 more instance...) 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: October 2002 Srihari R. Sangli 5 Procket Networks 7 Dynamic Capability for BGP-4 9 draft-ietf-idr-dynamic-cap-02.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 set to 0. 60 By advertising the Dynamic Capability to a peer in the OPEN, a BGP 61 speaker conveys to the peer that the speaker is capable of receiving 62 and properly handling the CAPABILITY message (as defined in the next 63 Section) from the peer after the BGP session has been established. 65 5. Capability Message 67 The CAPABILITY Message is a new BGP message type with type code 6. 68 In addition to the fixed-size BGP header [BGP-4], the CAPABILITY 69 message contains one or more of the following tuples: 71 +------------------------------+ 72 | Action (1 octet) | 73 +------------------------------+ 74 | Capability Code (1 octet) | 75 +------------------------------+ 76 | Capability Length (1 octet) | 77 +------------------------------+ 78 | Capability Value (variable) | 79 +------------------------------+ 81 The value of the Action field is 0 for advertising a capability, and 82 1 for removing a capability. 84 The triple is 85 the same as defined in [BGP-CAP], and it specifies a capability for 86 which the "Action" shall be applied. 88 6. Error Handling 90 A new NOTIFICATION error code is defined: 92 7 CAPABILITY Message Error 94 which has the following error subcodes: 96 1 Invalid Action Value 97 2 Invalid Capability Length 98 3 Malformed Capability Value 100 If the Action field of a received CAPABILITY message is other than 0 101 or 1, then a NOTIFICATION message with the error subcode "Invalid 102 Action Value" MUST be sent and the data field of the NOTIFICATION 103 message MUST contain the erroneous Action field. 105 If the Capability Length field of a received CAPABILITY message is 106 incorrect for a Capability Code, then a NOTIFICATION message with the 107 error subcode "Invalid Capability Length" MUST be sent and the data 108 field of the NOTIFICATION message MUST contain the Capability Code 109 and the Capability Length fields. 111 If the Capability Value field of a received CAPABILITY message is 112 malformed (the definition of "malformed" depends on the Capability 113 Code), then a NOTIFICATION message with the error subcode "Malformed 114 Capability Value" MUST be sent and the data field of the NOTIFICATION 115 message MUST contain the Capability Code, Capability Length, and the 116 Capability Value fields. 118 7. Operation 120 A BGP speaker that is willing to receive the CAPABILITY message from 121 its peer should advertise the Dynamic Capability to the peer using 122 BGP Capabilities advertisement [BGP-CAP]. 124 A BGP speaker may send a CAPABILITY message to its peer only if it 125 has received the Dynamic Capability from its peer. 127 The Dynamic Capability itself can not be revised dynamically via a 128 CAPABILITY message. The lifetime of the Dynamic Capability is the 129 duration of the BGP session in which the capability is advertised. 131 Upon receiving a CAPABILITY message from its peer, the BGP speaker 132 shall update the capabilities previously received from that peer 133 based on the "Action" in the message, and then function in accordance 134 with the revised capabilities for the peer. Any unrecognized 135 capabilities in the message should be ignored. 137 It is noted that the dynamic capability update may not be feasible 138 and should be disallowed for some capabilities. One example is the 139 four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update 140 could introduce ambiguity in parsing the UPDATE messages. 142 8. IANA Considerations 144 This document uses a BGP Capability code to indicate that a BGP 145 speaker supports the Dynamic Capability. The Capability code has 146 been assigned by IANA per RFC 2842. 148 9. Intellectual Property Considerations 150 Cisco Systems may seek patent or other intellectual property 151 protection for some of all of the technologies disclosed in this 152 document. If any standards arising from this document are or become 153 protected by one or more patents assigned to Cisco Systems, Cisco 154 intends to disclose those patents and license them on reasonable and 155 non-discriminatory terms. 157 10. Security Considerations 159 This extension to BGP does not change the underlying security issues. 161 11. Acknowledgments 163 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 164 Farinacci, Pedro Marques and Chandrashekhar Appanna for their review 165 and comments. We also would like to thank Bruno Rijsman for 166 suggesting the initial text for the Error Handling section. 168 12. References 170 [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 171 RFC 1771, March 1995. 173 [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 174 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 176 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 177 BGP-4", RFC 2842, May 2000. 179 [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS 180 number space", Work in Progress, , 181 September 2001. 183 13. Author Information 185 Enke Chen 186 Redback Networks, Inc. 187 350 Holger Way 188 San Jose, CA 95134 189 e-mail: enke@redback.com 191 Srihari R. Sangli 192 Procket Networks, Inc. 193 1100 Cadillac Court 194 Milpitas, CA 95035 195 e-mail: srihari@procket.com