idnits 2.17.1 draft-ietf-idr-dynamic-cap-00.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. 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: 7 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 2002 Srihari R. Sangli 5 Procket Networks 7 Dynamic Capability for BGP-4 9 draft-ietf-idr-dynamic-cap-00.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 68 . In addition to the fixed-size BGP header [BGP-4], the 69 CAPABILITY 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. Operation 90 A BGP speaker that is willing to receive the CAPABILITY message from 91 its peer should advertise the Dynamic Capability to the peer using 92 BGP Capabilities advertisement [BGP-CAP]. 94 A BGP speaker may send a CAPABILITY message to its peer only if it 95 has received the Dynamic Capability from its peer. 97 The Dynamic Capability itself can not be revised dynamically via a 98 CAPABILITY message. The lifetime of the Dynamic Capability is the 99 duration of the BGP session in which the capability is advertised. 101 Upon receiving a CAPABILITY message from its peer, the BGP speaker 102 shall update the capabilities previously received from that peer 103 based on the "Action" in the message, and then function in accordance 104 with the revised capabilities for the peer. Any unrecognized 105 capabilities in the message should be ignored. 107 It is noted that the dynamic capability update may not be feasible 108 and should be disallowed for some capabilities. One example is the 109 four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update 110 could introduce ambiguity in parsing the UPDATE messages. 112 7. IANA Considerations 114 This document uses a BGP Capability code to indicate that a BGP 115 speaker supports the Dynamic Capability. The Capability code needs 116 to be assigned by IANA per RFC 2842. Capability Code values 1 through 117 63 are to be assigned by IANA using the "IETF Consensus" policy 118 defined in RFC2434. 120 8. Intellectual Property Considerations 122 Cisco Systems may seek patent or other intellectual property 123 protection for some of all of the technologies disclosed in this 124 document. If any standards arising from this document are or become 125 protected by one or more patents assigned to Cisco Systems, Cisco 126 intends to disclose those patents and license them on reasonable and 127 non-discriminatory terms. 129 9. Security Considerations 131 This extension to BGP does not change the underlying security issues. 133 10. Acknowledgments 135 The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino 136 Farinacci, Pedro Marques and Chandrashekhar Appanna for their review 137 and comments. 139 11. References 141 [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 142 RFC 1771, March 1995. 144 [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 145 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 147 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 148 BGP-4", RFC 2842, May 2000. 150 [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS 151 number space", Work in Progress, , 152 May 2001. 154 12. Author Information 156 Enke Chen 157 Redback Networks, Inc. 158 350 Holger Way 159 San Jose, CA 95134 160 e-mail: enke@redback.com 162 Srihari R. Sangli 163 Procket Networks, Inc. 164 1100 Cadillac Court 165 Milpitas, CA 95035 166 e-mail: srihari@procket.com