idnits 2.17.1 draft-ietf-idr-cease-subcode-01.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 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 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) Summary: 6 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: December 2002 Vincent Gillet 5 France Telecom 7 Subcodes for BGP Cease Notification Message 9 draft-ietf-idr-cease-subcode-01.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 Administratively Shutdown 53 3 Peer Unconfigured 54 4 Administratively Reset 55 5 Connection Rejected 56 6 Other Configuration Change 58 5. Subcode Usage 60 If a BGP speaker decides to terminate its peering with a neighbor 61 because the number of address prefixes received from the neighbor 62 exceeds a locally configured upper bound (as described in [BGP-4]), 63 then the speaker must send to the neighbor a NOTIFICATION message 64 with the Error Code Cease, and the Error Subcode "Maximum Number of 65 Prefixes Reached". The message may optionally include the Address 66 Family information [BGP-MP] and the upper bound in the "Data" field 67 with the following format: 69 +-------------------------------+ 70 | AFI (2 octets) | 71 +-------------------------------+ 72 | SAFI (1 octet) | 73 +-------------------------------+ 74 | Prefix upper bound (4 octets) | 75 +-------------------------------+ 77 where the meaning and use of the tuple is the same as 78 defined in [BGP-MP, sect. 7]. 80 If a BGP speaker decides to administratively shut down its peering 81 with a neighbor, then the speaker should send a NOTIFICATION message 82 with the Error Code Cease, and the Error Subcode "Administratively 83 Shutdown". 85 If a BGP speaker decides to unconfigure a peer, then the speaker 86 should send a NOTIFICATION message with the Error Code Cease, and the 87 Error Subcode "Peer Unconfigured". 89 If a BGP speaker decides to administratively reset the peering with a 90 neighbor, then the speaker should send a NOTIFICATION message with 91 the Error Code Cease, and the Error Subcode "Administratively Reset". 93 If a BGP speaker decides to dis-allow a BGP connection (e.g., the 94 peer is not configured locally) after the speaker accepts a transport 95 protocol connection, then the BGP speaker should send a NOTIFICATION 96 message with the Error Code Cease, and the Error Subcode "Connection 97 Rejected". 99 If a BGP speaker decides to administratively reset the peering with a 100 neighbor due to a configuration change other than the ones described 101 above, then the speaker should send a NOTIFICATION message with the 102 Error Code Cease, and the Error Subcode "Other Configuration Change". 104 It is recommended that a BGP speaker implement a backoff mechanism in 105 re-trying a BGP connection after the speaker receives a Cease 106 NOTIFICATION message with subcode of "Administratively Shutdown", or 107 "Peer Unconfigured", or "Connection Rejected". An implementation may 108 impose an upper bound on the number of consecutive automatic retries. 109 Once this bound is reached, the implementation would stop re-trying 110 any BGP connections until some administrative intervention. 112 6. Security Considerations 114 This extension to BGP does not change the underlying security issues. 116 7. Acknowledgments 118 The authors would like to thank Yakov Rekhter for discussions and 119 review. 121 8. References 123 [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 124 , October 2001. 126 [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 127 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 129 9. Author Information 131 Enke Chen 132 Redback Networks, Inc. 133 350 Holger Way 134 San Jose, CA 95134 135 Email: enke@redback.com 137 Vincent Gillet 138 France Telecom Longues Distances 139 246 rue de Bercy 140 75594 Paris Cedex 12 FRANCE 141 Email : vgi@opentransit.net