idnits 2.17.00 (12 Aug 2021) /tmp/idnits11194/draft-ietf-idr-advisory-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 17, 2009) is 4592 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Scholl 3 Internet-Draft ATT 4 Intended status: Standards Track J. Scudder 5 Expires: April 20, 2010 Juniper Networks 6 R. Steenbergen 7 Server Central / nLayer 8 D. Freedman 9 Claranet Limited 10 October 17, 2009 12 BGP Advisory Message 13 draft-ietf-idr-advisory-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 20, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The BGP routing protocol is used with external as well as internal 52 neighbors to propagate route advertisements. In the case of external 53 BGP sessions, there is typically a demarcation of administrative 54 responsibility between the two entities. Provisioning, maintenance 55 and administrative actions are communicated via off-line methods such 56 as email or telephone calls. While these methods have been used for 57 many years, it can be troublesome for an operator to correlate a BGP- 58 related event in the network with a notice that was transmitted in 59 email. 61 This document proposes a new BGP message type, the Advisory message, 62 which can be used to convey advisory information to a BGP speaker's 63 peer. A capability is used to ensure that the recipient of the 64 Advisory message is capable of supporting it. 66 1. Introduction 68 The BGP routing protocol is used with external as well as internal 69 neighbors to propagate route advertisements. In the case of external 70 BGP sessions, there is typically a demarcation of administrative 71 responsibility between the two entities. While initial configuration 72 and troubleshooting of these sessions is handled via offline means 73 such as email or telephone calls, there is gap when it comes to 74 advising a BGP neighbor of a behavior that is occurring or will occur 75 momentarily. There is a need for operators to transmit a message to 76 a BGP neighbor to notify them of a variety of types of messages. 77 These messages typically would include those related to a planned or 78 unplanned maintenance action. These advisory messages could then be 79 interpreted by the remote party and either parsed via logging 80 mechanisms or viewed by a human on the remote end via the CLI. This 81 capability will improve operator NOC-to-NOC communication by 82 providing a communications medium on an established and trusted BGP 83 session between two autonomous systems. 85 The reason that this method is preferred for NOC-to-NOC 86 communications is that other offline methods do fail for a variety of 87 reasons. Emails to NOC aliases ahead of a planned maintanance may 88 have ignored the mail or may have not of recorded it properly within 89 an internal tracking system. Even if the message was recorded 90 properly, the staff that is on-duty at the time of the maintenance 91 event typically was not the same staff who received the maintenance 92 notice several days prior. In addition, the staff on duty at the 93 time of the event may not even be able to find the recorded event in 94 their internal tracking systems. The end result is that during a 95 planned event, some subset of eBGP peers will respond to a session/ 96 peer down event with additional communications to the operator who is 97 initiating the maintenance action. This can be via telephone or via 98 email, but either way, it may result in a sizable amount of replies 99 inquiring as to why the session is down. The result of this is that 100 the NOC responsible for initiating the maintenance can be innundated 101 with calls/emails from a variety of parties inquiring as to the 102 status of the BGP session. The NOC initating the maintenance may 103 have to further inquire with engineering staff (if they are not 104 already aware) to find out the extent of the maintenance and 105 communicate this back to all of the NOCs calling for additional 106 information. The above scenario outlines what is typical in a 107 planned maintenance event. In an unplanned maintenance event (the 108 need for and immediate router upgrade/reload), the number of calls 109 and emails will dramatically increase as more parties are unaware of 110 the event. 112 With the BGP advisory capability, an operator can transmit an 113 advisory message just prior to initiating the maintenance specifying 114 what event will happen, what ticket number this event is associated 115 with and the expected duration of the event. This message would be 116 received by BGP peers and stored in their router syslog as well as 117 any monitoring system if they have this capability. Now, all of the 118 BGP peers have immediate access to the information about this 119 session, why it went down, what ticket number this is being tracked 120 under and how long they should wait before assuming there is an 121 actual problem. Even smaller networks without the network management 122 capabilities to corrolate BGP events and advisory messages would 123 typically have an operator login to a router and examine the logs via 124 the CLI. 126 There are several problems with e-mail only notifications: 128 Up-to-date contact information is fairly difficult to maintain. 129 Some networks who have very open peering policies may peer with 130 up to 1,000 unique ASNs. 132 A NOC e-mail address does not always reach its way to the 133 proper individuals at the NOC. A large amount of e-mail 134 received at NOC aliases are typically spam or issues not 135 appropriate for a typical NOC queue. 137 E-mail is not real time. In some environments, e-mail 138 processing can be delayed and when looking at unplanned 139 maintenances, some operators do not have the time to draft an 140 e-mail as well as the distribution list. 142 There are several advantages to the advisory capability to operators: 144 There is no requirement for an external contact database. 145 Contact databases are important, but this capability provides a 146 way for an operator to transmit a message about a specific BGP 147 session with no external contact information being required. 149 The very existance of the BGP session itself has inherent 150 authentication and message routing properties. An operator 151 immediately knows for every advisory message that it is coming 152 from someone you are directly connected to (and thus have a 153 relationship with) and which particular BGP session this is 154 regarding. This is all completed without any additional human 155 parsing required. 157 Because there is a BGP session that exists, an operator already 158 has an authenticated session. There is no requirement for 159 further authentication of the BGP session (key exchange). 161 The advisory message provides for real-time delivery of a 162 message to a BGP neighbor. This will provide a rapid option in 163 comparison to drafting an email to all BGP peers and waiting 164 for the receipt before commencing with an unplanned maintenance 165 event. 167 This draft aims to provide operators with the capability to transmit 168 an advisory message to BGP peers to assist with daily network 169 operations. 171 1.1. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 2. Capability 179 A new BGP capability [RFC5492] called Advisory is introduced, with 180 type code TBD. This capability indicates that the router advertising 181 it is capable of receiving and parsing Advisory messages. The 182 capability is of variable length. The data portion of the capability 183 lists the Advisory message subtypes which are supported. The String 184 subtype MUST be supported, which implies that the length MUST be at 185 least 2 if the capability is advertised. 187 3. Advisory Message 189 The Advisory message is a BGP message of type TBD. It consists of a 190 BGP fixed header followed by a two-byte subtype and a data portion of 191 variable length, calculated according to the Length field in the 192 fixed header. The format of the data portion is dependent on the 193 subtype. This document defines the following subtypes: 195 0 - Reserved: 197 MUST NOT be sent, MUST be ignored (other than optionally 198 logging an error) on receipt. 200 1 - Advisory String: 202 A message comprised of a string of ASCII characters. The 203 string's length is given by the length of the message, there is 204 no null termination. Upon reception, the string SHOULD be 205 reported to the router's administrator. The means of reporting 206 the string are implementation-specific but could include 207 methods such as syslog. 209 2 - Static String: 211 A message comprised of a string of ASCII characters. The 212 string's length is given by the length of the message, there is 213 no null termination. Upon reception, the string SHOULD be 214 stored in a BGP neighbor statistics field within the router. 215 This string would then be accessable to the operator by 216 executing CLI commands or any other remote method to obtain BGP 217 neighbor statistics (NETCONF, SNMP). The expectation is that 218 the last static message received from a BGP neighbor will be 219 the message visible to the operator (the most current static 220 message). 222 While this document mandates no particular events for which advisory 223 messages should be generated, there are a variety of applications 224 where the advisory message may be used. Implementations SHOULD 225 provide its users the ability to transmit a free form text message 226 generated by user input. 228 Implementations MAY choose to define a standard set of advisory 229 messages that are automatically driven rather than requiring a human 230 to enter specific reasons. These messages may be automatically 231 transmitted based upon specific router functions such as a router 232 reload, administrative action (neighbor shutdown) or reconfiguration 233 (new BGP address-family support). 235 Implementations SHOULD provide router administrators with the ability 236 to filter out specific BGP Advisory message types on a per neighbor 237 or per peer-group basis. This interface should be provided to the 238 operator to clearly define if they want advisory, static or both 239 types of messages. 241 Implementations MUST rate-limit the rate in which they transmit and 242 receieve advisory messages. Specifically, an implementation MUST NOT 243 allow the handling of advisory messages to negatively impact any 244 other functions on a router such as regular BGP message handling or 245 other routing protocols. 247 As its name implies the Advisory message is intended to be used to 248 advise a peer of some condition which may be of interest to that peer 249 (or its administrator). It MUST NOT be used as a replacement for the 250 Notification message in fatal error situations (i.e., situations 251 where the integrity of the BGP peering is violated or suspect), 252 although an Advisory message MAY precede a Notification message. 254 4. Error Handling 256 An Advisory message MUST NOT be sent to any peer which has not 257 advertised the Advisory capability indicating support for the 258 relevant subtype. If a router which has advertised the Advisory 259 capability receives an Advisory message with a subtype for which it 260 has not advertised support, it MUST accept and discard that message. 261 It MAY locally log an error when this occurs. 263 5. IANA Considerations 265 IANA is requested to allocate a type code for the Advisory message 266 from the BGP Message Types registry, to allocate a type code for the 267 Advisory Capability from the Capability Codes registry, and to 268 establish and maintain a registry for BGP Advisory message subtypes, 269 to be allocated according to the First Come First Served policy 270 defined in [RFC5226]. 272 6. Security Considerations 274 No new security issues are introduced to the BGP protocol by this 275 specification. 277 7. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 283 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 284 May 2008. 286 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 287 with BGP-4", RFC 5492, February 2009. 289 Authors' Addresses 291 Tom Scholl 292 ATT 294 Email: tom.scholl@att.com 296 John Scudder 297 Juniper Networks 299 Email: jgs@juniper.net 301 Richard Steenbergen 302 Server Central / nLayer 304 Email: ras@e-gerbil.net 306 David Freedman 307 Claranet Limited 309 Email: david.freedman@uk.clara.net