idnits 2.17.1 draft-ietf-grow-bmp-02.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5400 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 (~~), 2 warnings (==), 1 comment (--). 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: January 14, 2010 S. Stuart 6 Google 7 July 13, 2009 9 BGP Monitoring Protocol 10 draft-ietf-grow-bmp-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 14, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document proposes a simple protocol, BMP, which can be used to 59 monitor BGP sessions. BMP is intended to provide a more convenient 60 interface for obtaining route views for research purpose than the 61 screen-scraping approach in common use today. The design goals are 62 to keep BMP simple, useful, easily implemented, and minimally 63 service-affecting. BMP is not suitable for use as a routing 64 protocol. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6 72 2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 73 2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 74 2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8 75 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Many researchers wish to have access to the contents of routers' BGP 90 RIBs as well as a view of protocol updates that the router is 91 receiving. This monitoring task cannot be realized by standard 92 protocol mechanisms. At present, this data can only be obtained 93 through screen-scraping. 95 The BMP protocol provides access to the Adj-RIB-In of a peer on an 96 ongoing basis and a periodic dump of certain statistics that the 97 monitoring station can use for further analysis. The following are 98 the messages provided by BMP. 100 o Route Monitoring (RM): An initial dump of all routes received from 101 a peer as well as an ongoing mechanism that sends the incremental 102 routes advertised and withdrawn by a peer to the monitoring 103 station. 105 o Peer Down Notification (PD): A message sent to indicate that a 106 peering session has gone down with information indicating the 107 reason for the session disconnect. 109 o Stats Reports (SR): This is an ongoing dump of statistics that can 110 be used by the monitoring station as a high level indication of 111 the activity going on in the router. 113 o Peer Up Notification (PU): A message sent to indicate that a 114 peering session has come up. The message includes information 115 regarding the data exchanged between the peers in their OPEN 116 messages as well as information about the peering TCP session 117 itself. 119 BMP operates over TCP. All options are controlled by configuration 120 on the monitored router. No message is ever sent from the monitoring 121 station to the monitored router. The monitored router MAY take steps 122 to prevent the monitoring station from sending data (e.g. by half- 123 closing the TCP session or setting its window size to zero) or it MAY 124 silently discard any data erroneously sent by the monitoring station. 126 The monitoring station is configured to listen on a particular TCP 127 port and the router is configured to establish an active connection 128 to that port and to send messages on that TCP connection. There is 129 no initialization or handshaking phase, messages are simply sent as 130 soon as the connection is established. If the router is unable to 131 connect to the monitoring station, it periodically retries the 132 connection. A suggested default retry period is 30 seconds. 134 If the monitoring station intends to restart BMP processing, it 135 simply drops the connection. The router then re-establishes the 136 connection and resends the messages. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. BMP Message Format 146 The following common header appears in all BMP messages. The rest of 147 the data in a BMP message is dependent on the "Message Type" field in 148 the common header. 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Version | Msg. Type | Peer Type | Peer Flags | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Peer Distinguisher (present based on peer type) | 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Peer Address (16 bytes) | 158 ~ ~ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Peer AS | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Peer BGP ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Timestamp (seconds) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Timestamp (microseconds) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 o Version (1 byte): Indicates the BMP version. This is set to '2' 170 for all messages defined in this specification. 172 o Message Type (1 byte): This identifies the type of the BMP 173 message, 175 * Type = 0: Route Monitoring 176 * Type = 1: Statistics Report 177 * Type = 2: Peer Down Notification 178 * Type = 3: Peer Up Notification 180 o Peer Type (1 byte): These bits identify the type of the peer. 181 Currently only two types of peers are identified, 182 * Peer Type = 0: Global Instance Peer 183 * Peer Type = 1: L3 VPN Instance Peer 185 o Peer Flags (1 byte): These flags provide more information about 186 the peer. The flags are defined as follows. 188 0 1 2 3 4 5 6 7 8 189 +-+-+-+-+-+-+-+-+ 190 |V|L| Reserved | 191 +-+-+-+-+-+-+-+-+ 193 * The V flag indicates the the Peer address is an IPv6 address. 194 For IPv4 peers this is set to 0. 195 * The L flag, if set to 1, indicates that the message reflects 196 the Loc-RIB (i.e., it reflects the application of inbound 197 policy). It is set to 0 if the message reflects the 198 Adj-RIB-In. 199 * The remaining bits are reserved for future use. 201 o Peer Distinguisher (8 bytes): Routers today can have multiple 202 instances (example L3VPNs). This field is present to distinguish 203 peers that belong to one address domain from the other. 205 If the peer is a "Global Instance Peer", this field is zero 206 filled. If the peer is a "L3VPN Instance Peer", it is set to the 207 route distinguisher of the particular L3VPN instance that the peer 208 belongs to. 210 o Peer Address: The remote IP address associated with the TCP 211 session over which the encapsulated PDU was received. It is 4 212 bytes long if an IPv4 address is carried in this field (with most 213 significant bytes zero filled) and 16 bytes long if an IPv6 214 address is carried in this field. 216 o Peer AS: The Autonomous System number of the peer from which the 217 encapsulated PDU was received. If a 16 bit AS number is stored in 218 this field [RFC4893], it should be padded with zeroes in the most 219 significant bits. 221 o Peer BGP ID: The BGP Identifier of the peer from which the 222 encapsulated PDU was received. 224 o Timestamp: The time when the encapsulated routes were received 225 (one may also think of this as the time when they were installed 226 in the Adj-RIB-In), expressed in seconds and microseconds since 227 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 228 unavailable. Precision of the timestamp is implementation- 229 dependent. 231 2.1. Route Monitoring 233 Route Monitoring messages are used for initial synchronization of 234 ADJ-RIB-In. They are also used for ongoing monitoring of received 235 advertisements and withdraws. This is discussed in more detail in 236 subsequent sections. 238 Following the common BMP header is a BGP PDU. The length of the PDU 239 can be determined by parsing it in the normal fashion as specified in 240 [RFC4271]. 242 2.2. Stats Reports 244 These messages contain information that could be used by the 245 monitoring station to observe interesting events that occur on the 246 router. 'Stats Report' messages have a message type of '3'. 248 The transmission of the SR messages could be timer triggered or event 249 driven (for example, when a significant event occurs or a threshold 250 is reached). This specification does not impose any timing 251 restrictions on when and on what event these reports have to be 252 transmitted. It is left to the implementation to determine 253 transmission timings -- however, configuration control should be 254 provided of the timer and/or threshold values. This document only 255 specifies the form and content of SR messages. 257 Following the common BMP header is a 4-byte field that indicates the 258 number of counters in the stats message where each counter is encoded 259 as a TLV. 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Stats Count | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Each counter is encoded as follows, 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Stat Type | Stat Len | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Stat Data | 273 ~ ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 o Stat Type (2 bytes): Defines the type of the statistic carried in 277 the "Stat Data" field. 279 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 281 This specification defines the following statistics. All statistics 282 are 4-byte quantities and the stats data are counters. 284 o Stat Type = 0: Number of prefixes rejected by inbound policy. 286 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 288 o Stat Type = 2: Number of (known) duplicate withdraws. 290 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 291 loop. 293 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 295 Note that the current specification only specifies 4-byte counters as 296 "Stat Data". This does not preclude future versions from 297 incorporating more complex TLV-type "Stat Data" (for example, one 298 which can carry prefix specific data). SR messages are optional. 299 However if an SR message is transmitted, this specification requires 300 at least one statistic to be carried in it. 302 2.3. Peer Down Notification 304 This message is used to indicate that a peering session was 305 terminated. The type of this message is 4. 307 0 1 2 3 4 5 6 7 8 308 +-+-+-+-+-+-+-+-+ 309 | 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Notification Message (present if Reason = 1 or 3) | 312 ~ ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Reason indicates why the session was closed. Defined values are: 317 o Reason 1: The local system closed the session. Following the 318 Reason is a BGP PDU containing a BGP NOTIFICATION message that 319 would have been sent to the peer. The length of the PDU can be 320 determined by parsing it in the normal fashion as specified in 321 [RFC4271]. 323 o Reason 2: The local system closed the session. No notification 324 message was sent. 326 o Reason 3: The remote system closed the session with a notification 327 message. Following the Reason is a BGP PDU containing the BGP 328 NOTIFICATION message as received from the peer. The length of the 329 PDU can be determined by parsing it in the normal fashion as 330 specified in [RFC4271]. 332 o Reason 4: The remote system closed the session without a 333 notification message. 335 2.4. Peer Up Notification 337 The Peer Up message is used to indicate that a peering session has 338 come up (i.e., has transitioned into ESTABLISHED state). Following 339 the common BMP header are the full OPEN messages as sent and received 340 by the BGP speaker. The OPEN message transmitted by the monitored 341 router to its peer is first, followed by the OPEN message received by 342 the monitored router from its peer. 344 The length of the full PU message is the length of the fixed header 345 plus the lengths of the two encapsulated OPEN messages which can be 346 determined by parsing them in the normal fashion as specified in 347 [RFC4271]. 349 3. Route Monitoring 351 After the BMP session is up, Route Monitoring messages are used to 352 provide a snapshot of the Adj-RIB-In of a particular peer. It does 353 so by sending all routes stored in the Adj-RIB-In of that peer using 354 standard BGP Update messages. There is no requirement on the 355 ordering of messages in the peer dump. 357 Depending on the implementation or configuration, it may only be 358 possible to send the Loc-RIB (post-policy routes) instead of the Adj- 359 RIB-In. This is because it is possible that a BGP implementation may 360 not store, for example, routes which have been filtered out by 361 policy. If this is the case, the implementation may send the Loc-RIB 362 path that pertains to a particular peer in the route monitor message. 364 If the implementation is able to provide information about when 365 routes were received, it MAY provide such information in the BMP 366 timestamp field. Otherwise, the BMP timestamp field MUST be set to 367 zero, indicating that time is not available. 369 Ongoing monitoring is accomplished by propagating route changes in 370 BGP UPDATE PDUs and forwarding those PDUs to the monitoring station, 371 again using RM messages. When a change occurs to a route, such as an 372 attribute change, the router must update the monitor with the new 373 attribute. When a route is withdrawn by a peer, a corresponding 374 withdraw is sent to the monitor. Multiple changed routes MAY be 375 grouped into a single BGP UPDATE PDU when feasible, exactly as in the 376 standard BGP protocol. 378 It's important to note that RM messages are not real time replicated 379 messages received from a peer. While the router should attempt to 380 generate updates as soon as they are received there is a finite time 381 that could elapse between reception of an update and the generation 382 an RM message and its transmission to the monitoring station. If 383 there are state changes in the interim for that prefix, it is 384 acceptable that the router generate the final state of that prefix to 385 the monitoring station. The actual PDU generated and transmitted to 386 the station might also differ from the exact PDU received from the 387 peer, for example due to differences between how different 388 implementations format path attributes. 390 4. Stat Reports 392 As outlined above, SR messages are used to monitor specific events 393 and counters on the monitored router. One type of monitoring could 394 be to find out if there are an undue number of route advertisements 395 and withdraws happening (churn) on the monitored router. Another 396 metric is to evaluate the number of looped AS-Paths on the router. 398 While this document proposes a small set of counters to begin with, 399 the authors envision this list may grow in the future with new 400 applications that require BMP style monitoring. 402 5. Other Considerations 404 Some routers may support multiple instances of the BGP protocol, for 405 example as "logical routers" or through some other facility. The BMP 406 protocol relates to a single instance of BGP; thus, if a router 407 supports multiple BGP instances it should also support multiple BMP 408 instances (one per BMP instance). 410 6. Using BMP 412 Once the BMP session is established route monitoring starts dumping 413 the current snapshot as well as incremental changes simultaneously. 415 It is fine to have these operations occur concurrently. If the 416 initial dump visits a route and subsequently a withdraw is received, 417 this will be forwarded to the monitoring station which would have to 418 correlate and reflect the deletion of that route in its internal 419 state. This is an operation a monitoring station would need to 420 support regardless. 422 If the router receives a withdraw for a prefix even before the peer 423 dump procedure visits that prefix, then the router would clean up 424 that route from its internal state and will not forward it to the 425 monitoring station. In this case, the monitoring station may receive 426 a bogus withdraw which it can safely ignore. 428 7. IANA Considerations 430 This document defines four message types for transferring BGP 431 messages between cooperating systems (Section 2): 433 o Type 0: Route Monitor 434 o Type 1: Statistics Report 435 o Type 2: Peer Down Notification 436 o Type 3: Peer Up Notification 438 Type values 4 through 255 MUST be assigned using the "IETF Consensus" 439 policy defined in [RFC5226]. 441 This document defines five statistics types for statistics reporting 442 (Section 2.2): 444 o Stat Type = 0: Number of prefixes rejected by inbound policy. 445 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 446 o Stat Type = 2: Number of (known) duplicate withdraws. 447 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 448 loop. 449 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 451 Stat Type values 5 through 32767 MUST be assigned using the "IETF 452 Consensus" policy, and values 32768 through 65535 using the "First 453 Come First Served" policy, defined in [RFC5226]. 455 8. Security Considerations 457 This document defines a mechanism to obtain a full dump or provide 458 continuous monitoring of a BGP speaker's local BGP table, including 459 received BGP messages. This capability could allow an outside party 460 to obtain information not otherwise obtainable. 462 Implementations of this protocol MUST require manual configuration of 463 the monitored and monitoring devices. 465 Users of this protocol MAY use some type of secure transmission 466 mechanism, such as IPSec [RFC4303], to transmit this data. 468 9. References 470 9.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 476 Protocol 4 (BGP-4)", RFC 4271, January 2006. 478 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 479 Number Space", RFC 4893, May 2007. 481 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 482 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 483 May 2008. 485 9.2. Informative References 487 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 488 RFC 4303, December 2005. 490 Appendix A. Changes Between BMP Versions 1 and 2 492 o Added Peer Up Message 493 o Added L flag 494 o Editorial changes 496 Authors' Addresses 498 John Scudder 499 Juniper Networks 500 1194 N. Mathilda Ave 501 Sunnyvale, CA 94089 502 USA 504 Email: jgs@juniper.net 505 Rex Fernando 506 Juniper Networks 507 1194 N. Mathilda Ave 508 Sunnyvale, CA 94089 509 USA 511 Email: rex@juniper.net 513 Stephen Stuart 514 Google 515 1600 Amphitheatre Parkway 516 Mountain View, CA 94043 517 USA 519 Email: sstuart@google.com