idnits 2.17.1 draft-ietf-idr-cease-subcode-03.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 121: '...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: February 2004 Vincent Gillet 5 France Telecom 7 Subcodes for BGP Cease Notification Message 9 draft-ietf-idr-cease-subcode-03.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 59 5. Subcode Usage 61 If a BGP speaker decides to terminate its peering with a neighbor 62 because the number of address prefixes received from the neighbor 63 exceeds a locally configured upper bound (as described in [BGP-4]), 64 then the speaker must send to the neighbor a NOTIFICATION message 65 with the Error Code Cease, and the Error Subcode "Maximum Number of 66 Prefixes Reached". The message may optionally include the Address 67 Family information [BGP-MP] and the upper bound in the "Data" field 68 with the following format: 70 +-------------------------------+ 71 | AFI (2 octets) | 72 +-------------------------------+ 73 | SAFI (1 octet) | 74 +-------------------------------+ 75 | Prefix upper bound (4 octets) | 76 +-------------------------------+ 78 where the meaning and use of the tuple is the same as 79 defined in [BGP-MP, sect. 7]. 81 If a BGP speaker decides to administratively shut down its peering 82 with a neighbor, then the speaker should send a NOTIFICATION message 83 with the Error Code Cease, and the Error Subcode "Administrative 84 Shutdown". 86 If a BGP speaker decides to unconfigure a peer, then the speaker 87 should send a NOTIFICATION message with the Error Code Cease, and the 88 Error Subcode "Peer Unconfigured". 90 If a BGP speaker decides to administratively reset the peering with a 91 neighbor, then the speaker should send a NOTIFICATION message with 92 the Error Code Cease, and the Error Subcode "Administrative Reset". 94 If a BGP speaker decides to dis-allow a BGP connection (e.g., the 95 peer is not configured locally) after the speaker accepts a transport 96 protocol connection, then the BGP speaker should send a NOTIFICATION 97 message with the Error Code Cease, and the Error Subcode "Connection 98 Rejected". 100 If a BGP speaker decides to administratively reset the peering with a 101 neighbor due to a configuration change other than the ones described 102 above, then the speaker should send a NOTIFICATION message with the 103 Error Code Cease, and the Error Subcode "Other Configuration Change". 105 If a BGP speaker decides to send a NOTIFICATION message with the 106 Error Code Cease as a result of the collision resolution procedure 107 (as described in [BGP-4]), then the subcode should be set to 108 "Connection Collision Resolution". 110 It is recommended that a BGP speaker implement a backoff mechanism in 111 re-trying a BGP connection after the speaker receives a Cease 112 NOTIFICATION message with subcode of "Administrative Shutdown", or 113 "Peer Unconfigured", or "Connection Rejected". An implementation may 114 impose an upper bound on the number of consecutive automatic retries. 115 Once this bound is reached, the implementation would stop re-trying 116 any BGP connections until some administrative intervention. 118 6. IANA Considerations 120 This document defines several subcodes for the BGP Cease NOTIFICATION 121 messsage. New subcodes MUST only be introduced using the Standards 122 Action process defined in [RFC-2434]. 124 7. Security Considerations 126 This extension to BGP does not change the underlying security issues. 128 8. Acknowledgments 130 The authors would like to thank Yakov Rekhter and Pedro Marques for 131 their review and suggestions. 133 9. References 135 [BGP-4] Y. Rekhter, T. Li and S. Hares, "A Border Gateway Protocol 4 136 (BGP-4)", , April 2003. 138 [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 139 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 141 [RFC-2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 142 IANA Considerations Section in RFCs", RFC 2434, October 1998. 144 10. Author Information 146 Enke Chen 147 Redback Networks, Inc. 148 350 Holger Way 149 San Jose, CA 95134 150 Email: enke@redback.com 152 Vincent Gillet 153 France Telecom Longues Distances 154 246 rue de Bercy 155 75594 Paris Cedex 12 FRANCE 156 Email: vgi@opentransit.net