idnits 2.17.1 draft-ietf-idr-cease-subcode-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): ---------------------------------------------------------------------------- ** 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 an Introduction section. ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4' ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Enke Chen 2 Internet Draft Redback Networks 3 Expiration Date: October 2004 Vincent Gillet 4 France Telecom 6 Subcodes for BGP Cease Notification Message 8 draft-ietf-idr-cease-subcode-05.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document defines several subcodes for the BGP Cease NOTIFICATION 34 message that would provide more information to aid network operators 35 in co-relating network events and diagnosing BGP peering issues. 37 3. Specification of Requirements 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC-2119]. 43 4. Introduction 45 This document defines several subcodes for the BGP Cease NOTIFICATION 46 message that would provide more information to aid network operators 47 in co-relating network events and diagnosing BGP peering issues. 49 5. Subcode Definition 51 The following subcodes are defined for the Cease NOTIFICATION 52 message: 54 Subcode Symbolic Name 56 1 Maximum Number of Prefixes Reached 57 2 Administrative Shutdown 58 3 Peer Unconfigured 59 4 Administrative Reset 60 5 Connection Rejected 61 6 Other Configuration Change 62 7 Connection Collision Resolution 63 8 Out of Resource 65 6. Subcode Usage 67 If a BGP speaker decides to terminate its peering with a neighbor 68 because the number of address prefixes received from the neighbor 69 exceeds a locally configured upper bound (as described in [BGP-4]), 70 then the speaker MUST send to the neighbor a NOTIFICATION message 71 with the Error Code Cease, and the Error Subcode "Maximum Number of 72 Prefixes Reached". The message MAY optionally include the Address 73 Family information [BGP-MP] and the upper bound in the "Data" field 74 with the following format: 76 +-------------------------------+ 77 | AFI (2 octets) | 78 +-------------------------------+ 79 | SAFI (1 octet) | 80 +-------------------------------+ 81 | Prefix upper bound (4 octets) | 82 +-------------------------------+ 84 where the meaning and use of the tuple is the same as 85 defined in [BGP-MP, sect. 7]. 87 If a BGP speaker decides to administratively shut down its peering 88 with a neighbor, then the speaker SHOULD send a NOTIFICATION message 89 with the Error Code Cease, and the Error Subcode "Administrative 90 Shutdown". 92 If a BGP speaker decides to unconfigure a peer, then the speaker 93 SHOULD send a NOTIFICATION message with the Error Code Cease, and the 94 Error Subcode "Peer Unconfigured". 96 If a BGP speaker decides to administratively reset the peering with a 97 neighbor, then the speaker SHOULD send a NOTIFICATION message with 98 the Error Code Cease, and the Error Subcode "Administrative Reset". 100 If a BGP speaker decides to dis-allow a BGP connection (e.g., the 101 peer is not configured locally) after the speaker accepts a transport 102 protocol connection, then the BGP speaker SHOULD send a NOTIFICATION 103 message with the Error Code Cease, and the Error Subcode "Connection 104 Rejected". 106 If a BGP speaker decides to administratively reset the peering with a 107 neighbor due to a configuration change other than the ones described 108 above, then the speaker SHOULD send a NOTIFICATION message with the 109 Error Code Cease, and the Error Subcode "Other Configuration Change". 111 If a BGP speaker decides to send a NOTIFICATION message with the 112 Error Code Cease as a result of the collision resolution procedure 113 (as described in [BGP-4]), then the subcode SHOULD be set to 114 "Connection Collision Resolution". 116 If a BGP speaker runs out of resource (e.g., memory) and decides to 117 reset a session, then the speaker MAY send a NOTIFICATION message 118 with the Error Code Cease, and the Error Subcode "Out of Resource". 120 It is RECOMMENDED that a BGP speaker implement a backoff mechanism in 121 re-trying a BGP connection after the speaker receives a Cease 122 NOTIFICATION message with subcode of "Administrative Shutdown", or 123 "Peer Unconfigured", or "Connection Rejected", or "Out of Resource". 124 An implementation MAY impose an upper bound on the number of 125 consecutive automatic retries. Once this bound is reached, the 126 implementation would stop re-trying any BGP connections until some 127 administrative intervention. 129 7. IANA Considerations 131 This document defines several subcodes for the BGP Cease NOTIFICATION 132 messsage. New subcodes MUST only be introduced using the Standards 133 Action process defined in [RFC-2434]. 135 8. Security Considerations 137 This extension to BGP does not change the underlying security issues 138 inherent in the existing BGP. 140 9. Acknowledgments 142 The authors would like to thank Yakov Rekhter, Pedro Marques, Andrew 143 Lange and Don Goodspeed for their review and suggestions. 145 10. References 147 [BGP-4] Y. Rekhter, T. Li and S. Hares, "A Border Gateway Protocol 4 148 (BGP-4)", , November 2003. 150 [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 151 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 153 [RFC-2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 154 IANA Considerations Section in RFCs", RFC 2434, October 1998. 156 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 157 Requirement Levels", BCP 14, RFC 2119, March 1997. 159 11. Author Information 161 Enke Chen 162 Redback Networks, Inc. 163 300 Holger Way 164 San Jose, CA 95134 165 Email: enke@redback.com 167 Vincent Gillet 168 France Telecom Longues Distances 169 246 rue de Bercy 170 75594 Paris Cedex 12 FRANCE 171 Email: vgi@opentransit.net