idnits 2.17.1 draft-ietf-idr-shutdown-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4486, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4486, updated by this document, for RFC5378 checks: 2001-10-18) -- 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.) -- The document date (November 30, 2016) is 2675 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Snijders 3 Internet-Draft NTT 4 Updates: 4486 (if approved) J. Heitz 5 Intended status: Standards Track Cisco 6 Expires: June 3, 2017 J. Scudder 7 Juniper 8 November 30, 2016 10 BGP Administrative Shutdown with Additional Communication 11 draft-ietf-idr-shutdown-01 13 Abstract 15 This document enhances the BGP Cease NOTIFICATION message 16 "Administrative Shutdown" subcode for operators to transmit a short 17 freeform message to describe why a BGP session was shutdown. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 3, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2 61 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 62 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 It can be troublesome for an operator to correlate a BGP-4 [RFC4271] 75 session teardown in the network with a notice that was transmitted 76 via off-line methods such email or telephone calls. This document 77 specifies a mechanism to transmit a short freeform UTF-8 [RFC3629] 78 message as part of a Cease NOTIFICATION message [RFC4486] to inform 79 the peer why the BGP session is being shutdown. 81 2. Shutdown Communication 83 If a BGP speaker decides to terminate its session with a BGP 84 neighbor, then the BGP speaker MAY send to the neighbor a 85 NOTIFICATION message with the Error Code "Cease" and the Error 86 Subcode "Administrative Shutdown" followed by a freeform UTF-8 87 encoded string with a REQUIRED maximum length of 128 octets. The 88 contents of the string are at the operator's discretion. 90 The Shutdown Communication Cease NOTIFICATION message is encoded as 91 below: 93 0 1 2 3 94 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Error code 6 | subcode 2 | Length | ... | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | ... Shutdown Communication ... | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | ... | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 The Length value can range from 0 to 128 and indicates how many 104 octets of Shutdown Communication follow. 106 To support international characters, the Shutdown Communication field 107 MUST be encoded using UTF-8. 109 The sending BGP speaker SHOULD avoid octet values below 32 (control 110 characters), however these values are legal. Following UNICODE TR36 111 [UTR36], Sec 3.1, the sending BGP speaker MUST encode messages in the 112 "shortest form" and MUST NOT interpret messages in the "non-shortest 113 form". A receiving BGP speaker MUST NOT interpret invalid UTF-8 114 sequences. 116 Mechanisms concerning the reporting of information contained in the 117 Shutdown Communication are implementation specific but SHOULD include 118 methods such as SYSLOG [RFC5424]. 120 3. Operational Considerations 122 Operators are encouraged to use the Shutdown Communication to inform 123 their peers of the reason for the shutdown of the BGP session and 124 include out-of-band reference materials. An example of a useful 125 Shutdown Communication would be: 127 "[TICKET-1-1438367390] software upgrade, back in 2 hours" 129 "[TICKET-1-1438367390]" is a ticket reference with significance to 130 both the sender and receiver, followed by a brief human readable 131 message regarding the reason for the BGP session shutdown followed by 132 an indication about the length of the maintenance. The receiver can 133 now use the string 'TICKET-1-1438367390' to search in their email 134 archive to find more details. 136 4. Error Handling 138 Any erroneous or malformed Shutdown Communication received SHOULD be 139 logged for the attention of the operator and then MAY be discarded. 141 5. IANA Considerations 143 Per this document, IANA is requested to reference this document at 144 subcode "Administrative Shutdown" in the "Cease NOTIFICATION message 145 subcodes" registry under the "Border Gateway Protocol (BGP) 146 Parameters" group. 148 6. Security Considerations 150 This document uses UTF-8 encoding for the Shutdown Communication. 151 There are a number of security issues with UNICODE. Implementers and 152 operator are advised to review UNICODE TR36 [UTR36] to learn about 153 these issues. This document guards against the technical issues 154 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 155 the visual spoofing due to character confusion still persists. This 156 document tries to minimize the effects of visual spoofing by allowing 157 UNICODE only where local script is expected and needed, and by 158 limiting the length of the Shutdown Communication. 160 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 162 This section records the status of known implementations of the 163 protocol defined by this specification at the time of posting of this 164 Internet-Draft, and is based on a proposal described in [RFC7942]. 165 The description of implementations in this section is intended to 166 assist the IETF in its decision processes in progressing drafts to 167 RFCs. Please note that the listing of any individual implementation 168 here does not imply endorsement by the IETF. Furthermore, no effort 169 has been spent to verify the information presented here that was 170 supplied by IETF contributors. This is not intended as, and must not 171 be construed to be, a catalog of available implementations or their 172 features. Readers are advised to note that other implementations may 173 exist. 175 As of today these vendors have produced an implementation of the 176 Shutdown Communication: 178 o ExaBGP 180 8. References 182 8.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, 187 . 189 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 190 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 191 2003, . 193 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 194 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 195 DOI 10.17487/RFC4271, January 2006, 196 . 198 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 199 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 200 April 2006, . 202 8.2. Informative References 204 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 205 DOI 10.17487/RFC5424, March 2009, 206 . 208 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 209 Code: The Implementation Status Section", BCP 205, 210 RFC 7942, DOI 10.17487/RFC7942, July 2016, 211 . 213 [UTR36] Davis, M. and M. Suignard, "Unicode Security 214 Considerations", Unicode Technical Report #36, August 215 2010, . 217 Appendix A. Acknowledgements 219 The authors would like to gratefully acknowledge Tom Scholl, David 220 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, and 221 John Heasley. 223 Authors' Addresses 225 Job Snijders 226 NTT Communications 227 Theodorus Majofskistraat 100 228 Amsterdam 1065 SZ 229 NL 231 Email: job@ntt.net 232 Jakob Heitz 233 Cisco 234 170 West Tasman Drive 235 San Jose, CA 95054 236 USA 238 Email: jheitz@cisco.com 240 John Scudder 241 Juniper Networks 242 1194 N. Mathilda Ave 243 Sunnyvale, CA 94089 244 USA 246 Email: jgs@juniper.net