idnits 2.17.1 draft-scholl-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.ii 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 (March 4, 2009) is 5530 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 AT&T 4 Intended status: Standards Track J. Scudder 5 Expires: September 5, 2009 Juniper Networks 6 March 4, 2009 8 BGP Advisory Message 9 draft-scholl-idr-advisory-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on September 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The BGP routing protocol is used with external as well as internal 48 neighbors to propagate route advertisements. In the case of external 49 BGP sessions, there is typically a demarcation of administrative 50 responsibility between the two entities. Provisioning, maintenance 51 and administrative actions are communicated via off-line methods such 52 as email or telephone calls. While these methods have been used for 53 many years, it can be troublesome for an operator to correlate a BGP- 54 related event in the network with a notice that was transmitted in 55 email. 57 This document proposes a new BGP message type, the Advisory message, 58 which can be used to convey advisory information to a BGP speaker's 59 peer. A capability is used to ensure that the recipient of the 60 Advisory message is capable of supporting it. 62 1. Introduction 64 The BGP routing protocol is used with external as well as internal 65 neighbors to propagate route advertisements. In the case of external 66 BGP sessions, there is typically a demarcation of administrative 67 responsibility between the two entities. Provisioning, maintenance 68 and administrative actions are communicated via off-line methods such 69 as email or telephone calls. While these methods have been used for 70 many years, it can be troublesome for an operator to correlate a BGP- 71 related event in the network with a notice that was transmitted in 72 email. 74 There are several events that require communication between the 75 administrators of peering routers. When a router is shut down for 76 maintenance resulting in BGP sessions to many neighbors being reset, 77 operators may be unable to correlate the event to an already notified 78 maintenance action. In addition, maintenance actions via email may 79 contain outdated trouble ticket information, incorrect router names 80 or incomplete time zones specified. Another complication is that 81 email based notifications are not always sent to the correct parties. 82 It is common in the settlement-free peering world for the 83 administrative/policy contacts to be separate from the technical/ 84 troubleshooting contacts. 86 This draft outlines a method to provide within BGP the ability to 87 transmit a text message to a BGP neighbor. This capability can speed 88 up operator reaction and resolution time by providing a direct 89 correlation between a BGP event and the root cause. This eliminates 90 the possibility for an operator to be "out of the loop" to any off- 91 line notifications of events. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Capability 101 A new BGP capability [RFC5492] called Advisory is introduced, with 102 type code TBD. This capability indicates that the router advertising 103 it is capable of receiving and parsing Advisory messages. The 104 capability is of variable length. The data portion of the capability 105 lists the Advisory message subtypes which are supported. The String 106 subtype MUST be supported, which implies that the length MUST be at 107 least 2 if the capability is advertised. 109 3. Advisory Message 111 The Advisory message is a BGP message of type TBD. It consists of a 112 BGP fixed header followed by a two-byte subtype and a data portion of 113 variable length, calculated according to the Length field in the 114 fixed header. The format of the data portion is dependent on the 115 subtype. This document defines the following subtypes: 117 0 - Reserved: 119 MUST NOT be sent, MUST be ignored (other than optionally 120 logging an error) on receipt. 122 1 - String: 124 A message comprised of a string of ASCII characters. The 125 string's length is given by the length of the message, there is 126 no null termination. Upon reception, the string SHOULD be 127 reported to the router's administrator. The means of reporting 128 the string are implementation-specific but could include 129 methods such as syslog. 131 While this document mandates no particular events for which advisory 132 messages should be generated, one suggested application is if a peer 133 is approaching a configured prefix limit. It is also likely that an 134 implementation will want to provide a way for an arbitrary, user- 135 specified string to be sent. Implementations MUST limit the rate at 136 which advisory messages are sent for any particular type of event. 138 As its name implies the Advisory message is intended to be used to 139 advise a peer of some condition which may be of interest to that peer 140 (or its administrator). It MUST NOT be used as a replacement for the 141 Notification message in fatal error situations (i.e., situations 142 where the integrity of the BGP peering is violated or suspect), 143 although an Advisory message MAY precede a Notification message. 145 4. Error Handling 147 An Advisory message MUST NOT be sent to any peer which has not 148 advertised the Advisory capability indicating support for the 149 relevant subtype. If a router which has advertised the Advisory 150 capability receives an Advisory message with a subtype for which it 151 has not advertised support, it MUST accept and discard that message. 152 It MAY locally log an error when this occurs. 154 5. IANA Considerations 156 IANA is requested to allocate a type code for the Advisory message 157 from the BGP Message Types registry, to allocate a type code for the 158 Advisory Capability from the Capability Codes registry, and to 159 establish and maintain a registry for BGP Advisory message subtypes, 160 to be allocated according to the First Come First Served policy 161 defined in [RFC5226]. 163 6. Security Considerations 165 No new security issues are introduced to the BGP protocol by this 166 specification. 168 7. Normative References 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", BCP 14, RFC 2119, March 1997. 173 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 174 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 175 May 2008. 177 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 178 with BGP-4", RFC 5492, February 2009. 180 Authors' Addresses 182 Tom Scholl 183 AT&T 185 Email: ts3127@att.com 187 John Scudder 188 Juniper Networks 190 Email: jgs@juniper.net