idnits 2.17.1 draft-ietf-idr-bgp4-cap-neg-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview of Operations' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 34 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) -- Missing reference section? 'BGP-4' on line 137 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ravi Chandra 3 Internet Draft Cisco Systems 4 Expiration Date: February 1999 John G. Scudder 5 Internet Engineering Group, LLC 7 Capabilities Negotiation with BGP-4 9 draft-ietf-idr-bgp4-cap-neg-02.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 2. Abstract 31 Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an 32 OPEN message with one or more unrecognized Optional Parameters, the 33 speaker must terminate BGP peering. This complicates introduction of 34 new capabilities in BGP. 36 This document defines new Optional Parameter, called Capabilities, 37 that is expected to facilitate introduction of new capabilities in 38 BGP by providing graceful capability negotiation without requiring 39 that BGP peering be terminated. 41 3. Overview of Operations 43 When a BGP speaker that supports capabilities negotiation sends an 44 OPEN message to its BGP peer, the message may include an Optional 45 Parameter, called Capabilities. The parameter lists the capabilities 46 supported by the speaker. 48 A BGP speaker determines the capabilities supported by its peer by 49 examining the list of capabilities present in the Capabilities 50 Optional Parameter carried by the OPEN message that the speaker 51 receives from the peer. 53 A BGP speaker that supports a particular capability may use this 54 capability with its peer after the speaker determines (as described 55 above) that the peer supports this capability. 57 A BGP speaker determines that its peer doesn't support capabilities 58 negotiation, if in response to an OPEN message that carries the 59 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 60 message with the Error Subcode set to Unsupported Optional Parameter. 61 In this case the speaker should attempt to re-establish a BGP 62 connection with the peer without sending to the peer the Capabilities 63 Optional Parameter. 65 If a BGP speaker that supports a certain capability determines that 66 its peer doesn't support this capability, the speaker may send a 67 NOTIFICATION message to the peer, and terminate peering. The Error 68 Subcode in the message is set to Unsupported Capability. The message 69 should contain the capability (capabilities) that causes the speaker 70 to send the message. The decision to send the message and terminate 71 peering is local to the speaker. Such peering should not be re- 72 established automatically. 74 4. Capabilities Optional Parameter (Parameter Type 2): 76 This is an Optional Parameter that is used by a BGP speaker to convey 77 to its BGP peer the list of capabilities supported by the speaker. 79 The parameter contains one or more triples , where each triple is encoded as 81 shown below: 83 +------------------------------+ 84 | Capability Code (1 octet) | 85 +------------------------------+ 86 | Capability Length (1 octet) | 87 +------------------------------+ 88 | Capability Value (variable) | 89 +------------------------------+ 91 The use and meaning of these fields are as follows: 93 Capability Code: 95 Capability Code is a one octet field that unambiguously 96 identifies individual capabilities. 98 Capability Length: 100 Capability Length is a one octet field that contains the length 101 of the Capability Value field in octets. 103 Capability Value: 105 Capability Value is a variable length field that is interpreted 106 according to the value of the Capability Code field. 108 A particular capability, as identified by its Capability Code, may 109 occur more than once within the Optional Parameter. 111 This document reserves Capability Codes 128-255 for vendor-specific 112 applications. 114 This document reserves value 0. 116 Capability Codes (other than those reserved for vendor specific use) 117 are assigned only by the IETF consensus process and IESG approval. 119 5. Extensions to Error Handling 121 This document defines new Error Subcode - Unsupported Capability. 122 The value of this Subcode is 7. The Data field in the NOTIFICATION 123 message lists the set of capabilities that cause the speaker to send 124 the message. Each such capability is encoded the same way as it was 125 encoded in the received OPEN message. 127 6. Security Considerations 129 This extension to BGP does not change the underlying security issues. 131 7. Acknowledgements 133 To be supplied. 135 8. References 137 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 138 4)", RFC 1771, March 1995. 140 9. Author Information 142 Ravi Chandra 143 Cisco Systems, Inc. 144 170 West Tasman Drive 145 San Jose, CA 95134 146 e-mail: rchandra@cisco.com 148 John G. Scudder 149 Internet Engineering Group, LLC 150 122 S. Main, Suite 280 151 Ann Arbor, MI 48104 152 e-mail: jgs@ieng.com