idnits 2.17.1 draft-snijders-idr-shutdown-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2016) is 2718 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Snijders 3 Internet-Draft NTT 4 Intended status: Standards Track J. Heitz 5 Expires: May 19, 2017 Cisco 6 J. Scudder 7 Juniper 8 November 15, 2016 10 The Shutdown Communication BGP Cease Notification Message subcode 11 draft-snijders-idr-shutdown-00 13 Abstract 15 This document defines the BGP Cease NOTIFICATION message "Shutdown 16 Communication" subcode for operators to transmit a short freeform 17 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 May 19, 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 TBD "Shutdown Communication" 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 following: 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 TBD | ... | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | ... Shutdown Communication ... | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | ... | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 To support international characters, the Shutdown Communication field 104 MUST be encoded using UTF-8. 106 The sending BGP speaker SHOULD avoid octet values below 32 (control 107 characters), however these values are legal. Following UNICODE TR36 108 [UTR36], Sec 3.1, the sending BGP speaker MUST encode messages in the 109 "shortest form" and MUST NOT interpret messages in the "non shortest 110 form". A receiving BGP speaker MUST NOT interpret invalid UTF-8 111 sequences. 113 It is RECOMMENDED that a BGP speaker receiving a Shutdown 114 Communication observe retry behaviour in line with the RFC4486 115 [RFC4486] behaviour for "Administrative Shutdown" (sec 4.0). 117 Mechanisms concerning the reporting of information contained in the 118 Shutdown Communication are implementation specific but SHOULD include 119 methods such as SYSLOG [RFC5424]. 121 3. Operational Considerations 123 Operators are encouraged to use the Shutdown Communication to inform 124 their peers with a reference and reason as to why the BGP session is 125 shut down. An example of a useful Shutdown Communication would be: 127 "[VNOC-1-1438367390] software upgrade, back in 2 hours" 129 "[VNOC-1-1438367390]" is a ticket reference with significance to both 130 the sender and receiver, followed by a brief human readable message 131 regarding the work triggering the BGP session shutdown followed by an 132 indication about the length of the maintenance. The receiver can now 133 use the string 'VNOC-1-1438367390' to search in their email archive 134 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 assign a subcode named 144 "Shutdown Communication" in the "Cease NOTIFICATION message subcodes" 145 registry under the "Border Gateway Protocol (BGP) Parameters" group. 147 6. Security Considerations 149 This document uses UTF-8 encoding for the Shutdown Communication. 150 There are a number of security issues with UNICODE. Any implementer 151 and operator is advised to review UNICODE TR36 [UTR36] to learn about 152 these issues. This document guards against the technical issues 153 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 154 the visual spoofing due to character confusion still persists. This 155 document tries to minimize the effects of visual spoofing by allowing 156 UNICODE only where local script is expected and needed, and by 157 limiting the length of the Shutdown Communication. 159 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 161 This section records the status of known implementations of the 162 protocol defined by this specification at the time of posting of this 163 Internet-Draft, and is based on a proposal described in [RFC7942]. 164 The description of implementations in this section is intended to 165 assist the IETF in its decision processes in progressing drafts to 166 RFCs. Please note that the listing of any individual implementation 167 here does not imply endorsement by the IETF. Furthermore, no effort 168 has been spent to verify the information presented here that was 169 supplied by IETF contributors. This is not intended as, and must not 170 be construed to be, a catalog of available implementations or their 171 features. Readers are advised to note that other implementations may 172 exist. 174 As of today these vendors have produced an implementation of the 175 Shutdown Communication: 177 o ExaBGP 179 8. References 181 8.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, 185 DOI 10.17487/RFC2119, March 1997, 186 . 188 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 189 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 190 2003, . 192 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 193 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 194 DOI 10.17487/RFC4271, January 2006, 195 . 197 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 198 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 199 April 2006, . 201 8.2. Informative References 203 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 204 DOI 10.17487/RFC5424, March 2009, 205 . 207 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 208 Code: The Implementation Status Section", BCP 205, 209 RFC 7942, DOI 10.17487/RFC7942, July 2016, 210 . 212 [UTR36] Davis, M. and M. Suignard, "Unicode Security 213 Considerations", Unicode Technical Report #36, August 214 2010, . 216 Appendix A. Acknowledgements 218 The author would like to gratefully acknowledge Tom Scholl, David 219 Freedman, and Jared Mauch. 221 Authors' Addresses 223 Job Snijders 224 NTT Communications 225 Theodorus Majofskistraat 100 226 Amsterdam 1065 SZ 227 NL 229 Email: job@ntt.net 230 Jakob Heitz 231 Cisco 232 170 West Tasman Drive 233 San Jose, CA 95054 234 USA 236 Email: jheitz@cisco.com 238 John Scudder 239 Juniper Networks 240 1194 N. Mathilda Ave 241 Sunnyvale, CA 94089 242 USA 244 Email: jgs@juniper.net