idnits 2.17.1 draft-scudder-bmp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. 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 Copyright Line does not match the current year -- 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 17, 2008) is 5637 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 4893 (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Scudder 3 Internet-Draft R. Fernando 4 Intended status: Standards Track Juniper Networks 5 Expires: May 21, 2009 S. Stuart 6 Google 7 November 17, 2008 9 BGP Monitoring Protocol 10 draft-scudder-bmp-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 21, 2009. 37 Abstract 39 This document proposes a simple protocol, BMP, which can be used to 40 monitor BGP sessions. BMP is intended to provide a more convenient 41 interface for obtaining route views for research purpose than the 42 screen-scraping approach in common use today. The design goals are 43 to keep BMP simple, useful, easily implemented, and minimally 44 service-affecting. BMP is not suitable for use as a routing 45 protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 5 53 2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 54 2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 55 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 56 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 12 66 1. Introduction 68 Many researchers wish to have access to the contents of routers' BGP 69 RIBs as well as a view of protocol updates that the router is 70 receiving. This monitoring task cannot be realized by standard 71 protocol mechanisms. At present, this data can only be obtained 72 through screen-scraping. 74 The BMP protocol provides access to the Adj-RIB-In of a peer on an 75 ongoing basis and a periodic dump of certain statistics that the 76 monitoring station can use for further analysis. The following are 77 the messages provided by BMP. 79 o Route Monitoring (RM): An initial dump of all routes received from 80 a peer as well as an ongoing mechanism that sends the incremental 81 routes advertised and withdrawn by a peer to the monitoring 82 station. 84 o Peer Down Notification (PD): A message sent to indicate that a 85 peering session has gone down with information indicating the 86 reason for the session disconnect. 88 o Stats Reports (SR): This is an ongoing dump of statistics that can 89 be used by the monitoring station as a high level indication of 90 the activity going on in the router. 92 BMP operates over TCP. All options are controlled by configuration 93 on the monitored router. Communication is unidirectional, from the 94 monitored router to the monitoring station. 96 The monitoring station is configured to listen on a particular TCP 97 port and the router is configured to establish an active connection 98 to that port and to send messages on that TCP connection. There is 99 no initialization or handshaking phase, messages are simply sent as 100 soon as the connection is established. 102 If the monitoring station intends to restart BMP processing, it 103 simply drops the connection. The router then re-establishes the 104 connection and resends the messages. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. BMP Message Format 114 The following common header appears in all BMP messages. The rest of 115 the data in a BMP message is dependent on the "Message Type" field in 116 the common header. 118 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Version | Msg. Type | Peer Type | Peer Flags | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Peer Distinguisher (present based on peer type) | 123 | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Peer Address (16 bytes) | 126 ~ ~ 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Peer AS | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Peer BGP ID | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Timestamp (seconds) | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Timestamp (microseconds) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 o Version (1 byte): Indicates the BMP version. This is set to '1' 138 for all messages defined in this specification. 140 o Message Type (1 byte): This identifies the type of the BMP 141 message, 143 * Type = 1: Route Monitoring 144 * Type = 2: Statistics Report 145 * Type = 3: Peer Down Notification 147 o Peer Type (1 byte): These bits identify the type of the peer. 148 Currently only two types of peers are identified, 150 * Peer Type = 0: Global Instance Peer 151 * Peer Type = 1: L3 VPN Instance Peer 153 o Peer Flags (1 byte): These flags provide more information about 154 the peer. The flags are defined as follows. 156 0 1 2 3 4 5 6 7 8 157 +-+-+-+-+-+-+-+-+ 158 |V| Reserved | 159 +-+-+-+-+-+-+-+-+ 161 * The V flag indicates the the Peer address is an IPv6 address. 162 For IPv4 peers this is set to 0. 163 * The remaining bits are reserved for future use. 165 o Peer Distinguisher (8 bytes): Routers today can have multiple 166 instances (example L3VPNs). This field is present to distinguish 167 peers that belong to one address domain from the other. 169 If the peer is a "Global Instance Peer", this field is zero 170 filled. If the peer is a "L3VPN Instance Peer", it is set to the 171 route distinguisher of the particular L3VPN instance that the peer 172 belongs to. 174 o Peer Address: The remote IP address associated with the TCP 175 session over which the encapsulated PDU was received. It is 4 176 bytes long if an IPv4 address is carried in this field (with most 177 significant bytes zero filled) and 16 bytes long if an IPv6 178 address is carried in this field. 180 o Peer AS: The Autonomous System number of the peer from which the 181 encapsulated PDU was received. If a 16 bit AS number is stored in 182 this field [RFC4893], it should be padded with zeroes in the most 183 significant bits. 185 o Peer BGP ID: The BGP Identifier of the peer from which the 186 encapsulated PDU was received. 188 o Timestamp: The time when the encapsulated PDU was received, 189 expressed in seconds and microseconds since midnight (zero hour), 190 January 1, 1970 (UTC). If zero, the time is unavailable. 192 2.1. Route Monitoring 194 Route Monitoring messages are used for initial synchronization of 195 ADJ-RIB-In. They are also used for ongoing monitoring of received 196 advertisements and withdraws. This is discussed in more detail in 197 subsequent sections. 199 Following the common BMP header is a BGP PDU. The length of the PDU 200 can be determined by parsing it in the normal fashion as specified in 201 [RFC4271]. 203 2.2. Stats Reports 205 These messages contain information that could be used by the 206 monitoring station to observe interesting events that occur on the 207 router. 'Stats Report' messages have a message type of '3'. 209 The transmission of the SR messages could be timer triggered or event 210 driven (for example, when a significant event occurs or a threshold 211 is reached). This specification does not impose any timing 212 restrictions on when and on what event these reports have to be 213 transmitted. It is left to the implementation to determine 214 transmission timings. This document only specifies the form and 215 content of SR messages. 217 Following the common BMP header is a 4-byte field that indicates the 218 number of counters in the stats message where each counter is encoded 219 as a TLV. 221 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Stats Count | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Each counter is encoded as follows, 228 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Stat Type | Stat Len | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Stat Data | 233 ~ ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 o Stat Type (2 bytes): Defines the type of the statistic carried in 237 the "Stat Data" field. 239 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 241 This specification defines the following statistics. All statistics 242 are 4-byte quantities and the stats data are counters. 244 o Stat Type = 1: Number of prefixes rejected by inbound policy. 246 o Stat Type = 2: Number of (known) duplicate prefix advertisements. 248 o Stat Type = 3: Number of (known) duplicate withdraws. 250 o Stat Type = 4: Number of updates invalidated due to CLUSTER_LIST 251 loop. 253 o Stat Type = 5: Number of updates invalidated due to AS_PATH loop. 255 Note that the current specification only specifies 4-byte counters as 256 "Stat Data". This does not preclude future versions from 257 incorporating more complex TLV-type "Stat Data" (for example, one 258 which can carry prefix specific data). SR messages are optional. 259 However if an SR message is transmitted, this specification requires 260 at least one statistic to be carried in it. 262 2.3. Peer Down Notification 264 This message is used to indicate that a peering session was 265 terminated. The type of this message is 4. 267 0 1 2 3 4 5 6 7 8 268 +-+-+-+-+-+-+-+-+ 269 | Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Notification Message (present if Reason = 1 or 3) | 272 ~ ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Reason indicates why the session was closed. Defined values are: 277 o Reason 1: The local system closed the session. Following the 278 Reason is a BGP PDU containing a BGP NOTIFICATION message that 279 would have been sent to the peer. The length of the PDU can be 280 determined by parsing it in the normal fashion as specified in 281 [RFC4271]. 283 o Reason 2: The local system closed the session. No notification 284 message was sent. 286 o Reason 3: The remote system closed the session with a notification 287 message. Following the Reason is a BGP PDU containing the BGP 288 NOTIFICATION message as received from the peer. The length of the 289 PDU can be determined by parsing it in the normal fashion as 290 specified in [RFC4271]. 292 o Reason 4: The remote system closed the session without a 293 notification message. 295 3. Route Monitoring 297 After the BMP session is up, Route Monitoring messages are used to 298 provide a snapshot of the Adj-RIB-In of a particular peer. It does 299 so by sending all routes stored in the Adj-RIB-In of that peer using 300 standard BGP Update messages. There is no requirement on the 301 ordering of messages in the peer dump. 303 Depending on the implementation or configuration, it may only be 304 possible to send the Loc-RIB (post-policy routes) instead of the Adj- 305 RIB-In. This is because it is possible that a BGP implementation may 306 not store, for example, routes which have been filtered out by 307 policy. If this is the case, the implementation may send the Loc-RIB 308 path that pertains to a particular peer in the route monitor message. 310 If the implementation is able to provide information about when 311 routes were received, it MAY provide such information in the BMP 312 timestamp field. Otherwise, the BMP timestamp field MUST be set to 313 zero, indicating that time is not available. 315 Ongoing monitoring is accomplished by propagating route changes in 316 BGP UPDATE PDUs and forwarding those PDUs to the monitoring station, 317 again using RM messages. When a change occurs to a route, such as an 318 attribute change, the router must update the monitor with the new 319 attribute. When a route is withdrawn by a peer, a corresponding 320 withdraw is sent to the monitor. Multiple changed routes MAY be 321 grouped into a single BGP UPDATE PDU when feasible, exactly as in the 322 standard BGP protocol. 324 It's important to note that RM messages are not real time replicated 325 messages received from a peer. While the router should attempt to 326 generate updates as soon as they are received there is a finite time 327 that could elapse between reception of an update and the generation 328 an RM message and its transmission to the monitoring station. If 329 there are state changes in the interim for that prefix, it is 330 acceptable that the router generate the final state of that prefix to 331 the monitoring station. The actual PDU generated and transmitted to 332 the station might also differ from the exact PDU received from the 333 peer, for example due to differences between how different 334 implementations format path attributes. 336 4. Stat Reports 338 As outlined above, SR messages are used to monitor specific events 339 and counters on the monitored router. One type of monitoring could 340 be to find out if there are an undue number of route advertisements 341 and withdraws happening (churn) on the monitored router. Another 342 metric is to evaluate the number of looped AS-Paths on the router. 344 While this document proposes a small set of counters to begin with, 345 the authors envision this list may grow in the future with new 346 applications that require BMP style monitoring. 348 5. Using BMP 350 Once the BMP session is established route monitoring starts dumping 351 the current snapshot as well as incremental changes simultaneously. 353 It is fine to have these operations occur concurrently. If the 354 initial dump visits a route and subsequently a withdraw is received, 355 this will be forwarded to the monitoring station which would have to 356 correlate and reflect the deletion of that route in its internal 357 state. This is an operation a monitoring station would need to 358 support regardless. 360 If the router receives a withdraw for a prefix even before the peer 361 dump procedure visits that prefix, then the router would clean up 362 that route from its internal state and will not forward it to the 363 monitoring station. In this case, the monitoring station may receive 364 a bogus withdraw which it can safely ignore. 366 6. IANA Considerations 368 This document defines three message types for transferring BGP 369 messages between cooperating systems (Section 2): 371 o Type 1: Route Monitor 372 o Type 2: Statistics Report 373 o Type 3: Peer Down Notification 375 Type values 4 through 255 MUST be assigned using the "IETF Consensus" 376 policy defined in [RFC5226]. 378 This document defines five statistics types for statistics reporting 379 (Section 2.2): 381 o Stat Type = 1: Number of prefixes rejected by inbound policy. 382 o Stat Type = 2: Number of (known) duplicate prefix advertisements. 383 o Stat Type = 3: Number of (known) duplicate withdraws. 384 o Stat Type = 4: Number of updates invalidated due to CLUSTER_LIST 385 loop. 387 o Stat Type = 5: Number of updates invalidated due to AS_PATH loop. 389 Stat Type values 6 through 32767 MUST be assigned using the "IETF 390 Consensus" policy, and values 32768 through 65535 using the "First 391 Come First Served" policy, defined in [RFC5226]. 393 7. Security Considerations 395 This document defines a mechanism to obtain a full dump or provide 396 continuous monitoring of a BGP speaker's local BGP table, including 397 received BGP messages. This capability could allow an outside party 398 to obtain information not otherwise obtainable. 400 Implementations of this protocol MUST require manual configuration of 401 the monitored and monitoring devices. 403 Users of this protocol MAY use some type of secure transmission 404 mechanism, such as IPSec [RFC4303], to transmit this data. 406 8. References 408 8.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 414 Protocol 4 (BGP-4)", RFC 4271, January 2006. 416 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 417 Number Space", RFC 4893, May 2007. 419 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 420 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 421 May 2008. 423 8.2. Informative References 425 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 426 RFC 4303, December 2005. 428 Authors' Addresses 430 John Scudder 431 Juniper Networks 432 1194 N. Mathilda Ave 433 Sunnyvale, CA 94089 434 USA 436 Email: jgs@juniper.net 438 Rex Fernando 439 Juniper Networks 440 1194 N. Mathilda Ave 441 Sunnyvale, CA 94089 442 USA 444 Email: rex@juniper.net 446 Stephen Stuart 447 Google 448 1600 Amphitheatre Parkway 449 Mountain View, CA 94043 450 USA 452 Email: sstuart@google.com 454 Full Copyright Statement 456 Copyright (C) The IETF Trust (2008). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 465 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 466 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org.