idnits 2.17.1 draft-ietf-idr-cease-subcode-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 3 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 4 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 127: '...e. New subcodes MUST only be introduc...' 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. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Redback Networks 4 Expiration Date: March 2004 Vincent Gillet 5 France Telecom 7 Subcodes for BGP Cease Notification Message 9 draft-ietf-idr-cease-subcode-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. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 This document defines several subcodes for the BGP Cease NOTIFICATION 35 message that would provide more information to aid network operators 36 in co-relating network events and diagnosing BGP peering issues. 38 3. Introduction 40 This document defines several subcodes for the BGP Cease NOTIFICATION 41 message that would provide more information to aid network operators 42 in co-relating network events and diagnosing BGP peering issues. 44 4. Subcode Definition 46 The following subcodes are defined for the Cease NOTIFICATION 47 message: 49 Subcode Symbolic Name 51 1 Maximum Number of Prefixes Reached 52 2 Administrative Shutdown 53 3 Peer Unconfigured 54 4 Administrative Reset 55 5 Connection Rejected 56 6 Other Configuration Change 57 7 Connection Collision Resolution 58 8 Out of Resource 60 5. Subcode Usage 62 If a BGP speaker decides to terminate its peering with a neighbor 63 because the number of address prefixes received from the neighbor 64 exceeds a locally configured upper bound (as described in [BGP-4]), 65 then the speaker must send to the neighbor a NOTIFICATION message 66 with the Error Code Cease, and the Error Subcode "Maximum Number of 67 Prefixes Reached". The message may optionally include the Address 68 Family information [BGP-MP] and the upper bound in the "Data" field 69 with the following format: 71 +-------------------------------+ 72 | AFI (2 octets) | 73 +-------------------------------+ 74 | SAFI (1 octet) | 75 +-------------------------------+ 76 | Prefix upper bound (4 octets) | 77 +-------------------------------+ 79 where the meaning and use of the tuple is the same as 80 defined in [BGP-MP, sect. 7]. 82 If a BGP speaker decides to administratively shut down its peering 83 with a neighbor, then the speaker should send a NOTIFICATION message 84 with the Error Code Cease, and the Error Subcode "Administrative 85 Shutdown". 87 If a BGP speaker decides to unconfigure a peer, then the speaker 88 should send a NOTIFICATION message with the Error Code Cease, and the 89 Error Subcode "Peer Unconfigured". 91 If a BGP speaker decides to administratively reset the peering with a 92 neighbor, then the speaker should send a NOTIFICATION message with 93 the Error Code Cease, and the Error Subcode "Administrative Reset". 95 If a BGP speaker decides to dis-allow a BGP connection (e.g., the 96 peer is not configured locally) after the speaker accepts a transport 97 protocol connection, then the BGP speaker should send a NOTIFICATION 98 message with the Error Code Cease, and the Error Subcode "Connection 99 Rejected". 101 If a BGP speaker decides to administratively reset the peering with a 102 neighbor due to a configuration change other than the ones described 103 above, then the speaker should send a NOTIFICATION message with the 104 Error Code Cease, and the Error Subcode "Other Configuration Change". 106 If a BGP speaker decides to send a NOTIFICATION message with the 107 Error Code Cease as a result of the collision resolution procedure 108 (as described in [BGP-4]), then the subcode should be set to 109 "Connection Collision Resolution". 111 If a BGP speaker runs out of resource (e.g., memory) and decides to 112 reset a session, then the speaker may send a NOTIFICATION message 113 with the Error Code Cease, and the Error Subcode "Out of Resource". 115 It is recommended that a BGP speaker implement a backoff mechanism in 116 re-trying a BGP connection after the speaker receives a Cease 117 NOTIFICATION message with subcode of "Administrative Shutdown", or 118 "Peer Unconfigured", or "Connection Rejected", or "Out of Resource". 119 An implementation may impose an upper bound on the number of 120 consecutive automatic retries. Once this bound is reached, the 121 implementation would stop re-trying any BGP connections until some 122 administrative intervention. 124 6. IANA Considerations 126 This document defines several subcodes for the BGP Cease NOTIFICATION 127 messsage. New subcodes MUST only be introduced using the Standards 128 Action process defined in [RFC-2434]. 130 7. Security Considerations 132 This extension to BGP does not change the underlying security issues. 134 8. Acknowledgments 136 The authors would like to thank Yakov Rekhter, Pedro Marques, Andrew 137 Lange and Don Goodspeed for their review and suggestions. 139 9. References 141 [BGP-4] Y. Rekhter, T. Li and S. Hares, "A Border Gateway Protocol 4 142 (BGP-4)", , April 2003. 144 [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 145 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 147 [RFC-2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 148 IANA Considerations Section in RFCs", RFC 2434, October 1998. 150 10. Author Information 152 Enke Chen 153 Redback Networks, Inc. 154 300 Holger Way 155 San Jose, CA 95134 156 Email: enke@redback.com 158 Vincent Gillet 159 France Telecom Longues Distances 160 246 rue de Bercy 161 75594 Paris Cedex 12 FRANCE 162 Email: vgi@opentransit.net