idnits 2.17.1 draft-ietf-grow-bmp-08.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 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 (May 22, 2015) is 3262 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: 1 error (**), 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 Juniper Networks 4 Intended status: Standards Track R. Fernando 5 Expires: November 23, 2015 Cisco Systems 6 S. Stuart 7 Google 8 May 22, 2015 10 BGP Monitoring Protocol 11 draft-ietf-grow-bmp-08 13 Abstract 15 This document defines a protocol, BMP, which can be used to monitor 16 BGP sessions. BMP is intended to provide a more convenient interface 17 for obtaining route views for research purpose than the screen- 18 scraping approach in common use today. The design goals are to keep 19 BMP simple, useful, easily implemented, and minimally service- 20 affecting. BMP is not suitable for use as a routing protocol. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 23, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Overview of BMP Operation . . . . . . . . . . . . . . . . . . 4 72 3.1. BMP Messages . . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Connection Establishment and Termination . . . . . . . . 4 74 3.3. Lifecycle of a BMP Session . . . . . . . . . . . . . . . 5 75 4. BMP Message Format . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 6 77 4.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Initiation Message . . . . . . . . . . . . . . . . . . . 9 79 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9 80 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10 81 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11 82 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11 83 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12 84 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14 85 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 86 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 87 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 88 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 18 91 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 92 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 95 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 96 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 20 97 10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 98 10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 99 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 21 100 10.7. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 22 101 10.8. BMP Route Mirroring Information Codes . . . . . . . . . 22 102 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 106 13.2. Informative References . . . . . . . . . . . . . . . . . 23 107 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 24 108 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 Many researchers wish to have access to the contents of routers' BGP 114 RIBs as well as a view of protocol updates that the router is 115 receiving. This monitoring task cannot be realized by standard 116 protocol mechanisms. Prior to introduction of BMP, this data could 117 only be obtained through screen-scraping. 119 The BMP protocol provides access to the Adj-RIB-In of a peer on an 120 ongoing basis and a periodic dump of certain statistics that the 121 monitoring station can use for further analysis. From a high level, 122 BMP can be thought of as the result of multiplexing together the 123 messages received on the various monitored BGP sessions. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in RFC 130 2119 [RFC2119]. 132 2. Definitions 134 o Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains 135 unprocessed routing information that has been advertised to the 136 local BGP speaker by its peers." This is also referred to as the 137 pre-policy Adj-RIB-In in this document. 139 o Post-Policy Adj-RIB-In: The result of applying inbound policy to 140 an Adj-RIB-In, but prior to the application of route selection to 141 form the Loc-RIB. 143 3. Overview of BMP Operation 145 3.1. BMP Messages 147 The following are the messages provided by BMP. 149 o Route Monitoring (RM): An initial dump of all routes received from 150 a peer as well as an ongoing mechanism that sends the incremental 151 routes advertised and withdrawn by a peer to the monitoring 152 station. 154 o Peer Down Notification (PD): A message sent to indicate that a 155 peering session has gone down with information indicating the 156 reason for the session disconnect. 158 o Stats Reports (SR): An ongoing dump of statistics that can be used 159 by the monitoring station as a high level indication of the 160 activity going on in the router. 162 o Peer Up Notification (PU): A message sent to indicate that a 163 peering session has come up. The message includes information 164 regarding the data exchanged between the peers in their OPEN 165 messages as well as information about the peering TCP session 166 itself. In addition to being sent whenever a peer transitions to 167 ESTABLISHED state, a Peer Up Notification is sent for each peer 168 that is in ESTABLISHED state when the BMP session itself comes up. 170 o Initiation: A means for the monitored router to inform the 171 monitoring station of its vendor, software version, and so on. 173 o Termination: A means for the monitored router to inform the 174 monitoring station of why it is closing a BMP session. 176 o Route Mirroring: a means for the monitored router to send verbatim 177 duplicates of messages as received. Can be used to exactly mirror 178 a monitored BGP session. Can also be used to report malformed BGP 179 PDUs. 181 3.2. Connection Establishment and Termination 183 BMP operates over TCP. All options are controlled by configuration 184 on the monitored router. No message is ever sent from the monitoring 185 station to the monitored router. The monitored router MAY take steps 186 to prevent the monitoring station from sending data (for example by 187 half-closing the TCP session or setting its window size to zero) or 188 it MAY silently discard any data sent by the monitoring station. 190 The router may be monitored by one or more monitoring stations. With 191 respect to each (router, monitoring station) pair, one party is 192 active with respect to TCP session establishment, and the other party 193 is passive. Which party is active and which is passive is controlled 194 by configuration. 196 The passive party is configured to listen on a particular TCP port 197 and the active party is configured to establish a connection to that 198 port. If the active party is unable to connect to the passive party, 199 it periodically retries the connection. Retries MUST be subject to 200 some variety of backoff. Exponential backoff with a default initial 201 backoff of 30 seconds and a maximum of 720 seconds is suggested. 203 The router MAY restrict the set of IP addresses from which it will 204 accept connections. It SHOULD restrict the number of simultaneous 205 connections it will permit from a given IP address. The default 206 value for this restriction SHOULD be 1, though an implementation MAY 207 permit this restriction to be disabled in configuration. The router 208 MUST also restrict the rate at which sessions may be established. A 209 suggested default is an establishment rate of 2 sessions per minute. 211 A router (or management station) MAY implement logic to detect 212 redundant connections, as might occur if both parties are configured 213 to be active, and MAY elect to terminate redundant connections. A 214 Termination reason code is defined for this purpose. 216 Once a connection is established, the router sends messages over it. 217 There is no initialization or handshaking phase, messages are simply 218 sent as soon as the connection is established. 220 If the monitoring station intends to restart BMP processing, it 221 simply drops the connection, optionally with a Termination message. 223 3.3. Lifecycle of a BMP Session 225 A router is configured to speak BMP with one or more monitoring 226 stations. It MAY be configured to send monitoring information for 227 only a subset of its BGP peers. Otherwise, all BGP peers are assumed 228 to be monitored. 230 A BMP session begins when the active party (either router or 231 management station, as determined by configuration) successfully 232 opens a TCP session (the "BMP session"). Once the session is up, the 233 router begins to send BMP messages. It MUST begin by sending an 234 Initiation message. It subsequently sends a Peer Up message over the 235 BMP session for each of its monitored BGP peers which are in 236 Established state. It follows by sending the contents of its Adj- 237 RIBs-In (pre-policy, post-policy or both, see Section 5) encapsulated 238 in Route Monitoring messages. Once it has sent all the routes for a 239 given peer, it MUST send a End-of-RIB message for that peer; when 240 End-of-RIB has been sent for each monitored peer, the initial table 241 dump has completed. (A monitoring station that wishes only to gather 242 a table dump could close the connection once it has gathered an End- 243 of-RIB or Peer Down message corresponding to each Peer Up message.) 245 Following the initial table dump, the router sends incremental 246 updates encapsulated in Route Monitoring messages. It MAY 247 periodically send Stats Reports or even new Initiation messages, 248 according to configuration. If any new monitored BGP peers become 249 Established, corresponding Peer Up messages are sent. If any BGP 250 peers for which Peer Up messages were sent transition out of the 251 Established state, corresponding Peer Down messages are sent. 253 A BMP session ends when the TCP session that carries it is closed for 254 any reason. The router MAY send a Termination message prior to 255 closing the session. 257 4. BMP Message Format 259 4.1. Common Header 261 The following common header appears in all BMP messages. The rest of 262 the data in a BMP message is dependent on the "Message Type" field in 263 the common header. 265 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 266 +-+-+-+-+-+-+-+-+ 267 | Version | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Message Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Msg. Type | 272 +---------------+ 274 o Version (1 byte): Indicates the BMP version. This is set to '3' 275 for all messages defined in this specification. Version 0 is 276 reserved and MUST NOT be sent. 278 o Message Length (4 bytes): Length of the message in bytes 279 (including headers, data and encapsulated messages, if any). 281 o Message Type (1 byte): This identifies the type of the BMP 282 message. A BMP implementation MUST ignore unrecognized message 283 types upon receipt. 285 * Type = 0: Route Monitoring 286 * Type = 1: Statistics Report 287 * Type = 2: Peer Down Notification 288 * Type = 3: Peer Up Notification 289 * Type = 4: Initiation Message 290 * Type = 5: Termination Message 292 4.2. Per-Peer Header 294 The per-peer header follows the common header for most BMP messages. 295 The rest of the data in a BMP message is dependent on the "Message 296 Type" field in the common header. 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Peer Type | Peer Flags | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Peer Distinguisher (present based on peer type) | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Peer Address (16 bytes) | 306 ~ ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Peer AS | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Peer BGP ID | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Timestamp (seconds) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Timestamp (microseconds) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 o Peer Type (1 byte): These bits identify the type of the peer. 318 Currently only two types of peers are identified, 320 * Peer Type = 0: Global Instance Peer 321 * Peer Type = 1: L3 VPN Instance Peer 323 o Peer Flags (1 byte): These flags provide more information about 324 the peer. The flags are defined as follows. 326 0 1 2 3 4 5 6 7 8 327 +-+-+-+-+-+-+-+-+ 328 |V|L|A| Reserved| 329 +-+-+-+-+-+-+-+-+ 331 * The V flag indicates the the Peer address is an IPv6 address. 332 For IPv4 peers this is set to 0. 333 * The L flag, if set to 1, indicates that the message reflects 334 the post-policy Adj-RIB-In (i.e., its path attributes reflect 335 the application of inbound policy). It is set to 0 if the 336 message reflects the pre-policy Adj-RIB-In. Locally-sourced 337 routes also carry an L flag of 1. See Section 5 for further 338 detail. This flag has no significance when used with route 339 mirroring messages (Section 4.7). 340 * The A flag, if set to 1, indicates that the message is 341 formatted using the legacy two-byte AS_PATH format. If set to 342 0, the message is formatted using the four-byte AS_PATH format 343 [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH 344 information as received from its peer, or it MAY choose to 345 reformat all AS_PATH information into four-byte format 346 regardless of how it was received from the peer. In the latter 347 case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be 348 sent in the BMP UPDATE message. This flag has no significance 349 when used with route mirroring messages (Section 4.7). 350 * The remaining bits are reserved for future use. 352 o Peer Distinguisher (8 bytes): Routers today can have multiple 353 instances (example L3VPNs). This field is present to distinguish 354 peers that belong to one address domain from the other. 356 If the peer is a "Global Instance Peer", this field is zero 357 filled. If the peer is a "L3VPN Instance Peer", it is set to the 358 route distinguisher of the particular L3VPN instance that the peer 359 belongs to. 361 o Peer Address: The remote IP address associated with the TCP 362 session over which the encapsulated PDU was received. It is 4 363 bytes long if an IPv4 address is carried in this field (with most 364 significant bytes zero filled) and 16 bytes long if an IPv6 365 address is carried in this field. 367 o Peer AS: The Autonomous System number of the peer from which the 368 encapsulated PDU was received. If a 16 bit AS number is stored in 369 this field [RFC6793], it should be padded with zeroes in the most 370 significant bits. 372 o Peer BGP ID: The BGP Identifier of the peer from which the 373 encapsulated PDU was received. 375 o Timestamp: The time when the encapsulated routes were received 376 (one may also think of this as the time when they were installed 377 in the Adj-RIB-In), expressed in seconds and microseconds since 378 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 379 unavailable. Precision of the timestamp is implementation- 380 dependent. 382 4.3. Initiation Message 384 The initiation message provides a means for the monitored router to 385 inform the monitoring station of its vendor, software version, and so 386 on. An initiation message MUST be sent as the first message after 387 the TCP session comes up. An initiation message MAY be sent at any 388 point thereafter, if warranted by a change on the monitored router. 390 The initiation message consists of the common BMP header followed by 391 two or more Information TLVs (Section 4.4) containing information 392 about the monitored router. The sysDescr and sysName Information 393 TLVs MUST be sent, any others are optional. The string TLV MAY be 394 included multiple times. 396 4.4. Information TLV 398 The Information TLV is used by the Initiation (Section 4.3) and Peer 399 Up (Section 4.10) messages. 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Information Type | Information Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Information (variable) | 406 ~ ~ 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 o Information Type (2 bytes): Type of information provided. Defined 410 types are: 412 * Type = 0: String. The Information field contains a free-form 413 UTF-8 string whose length is given by the "Information Length" 414 field. The value is administratively assigned. Note that 415 there is no requirement to terminate the string with a null (or 416 any other particular) character -- the length field gives its 417 termination. If multiple strings are included, their ordering 418 MUST be preserved when they are reported. 420 * Type = 1: sysDescr. The Information field contains an ASCII 421 string whose value MUST be set to be equal to the value of the 422 sysDescr MIB-II [RFC1213] object. 424 * Type = 2: sysName. The Information field contains a ASCII 425 string whose value MUST be set to be equal to the value of the 426 sysName MIB-II [RFC1213] object. 428 o Information Length (2 bytes): The length of the following 429 Information field, in bytes. 431 o Information (variable): Information about the monitored router, 432 according to the type. 434 4.5. Termination Message 436 The termination message provides a way for a monitored router to 437 indicate why it is terminating a session. Although use of this 438 message is RECOMMENDED, a monitoring station must always be prepared 439 for the session to terminate with no message. Once the router has 440 sent a termination message, it MUST close the TCP session without 441 sending any further messages. Likewise, the monitoring station MUST 442 close the TCP session after receiving a termination message. 444 The termination message consists of the common BMP header followed by 445 one or more TLVs containing information about the reason for the 446 termination, as follows: 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Information Type | Information Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Information (variable) | 453 ~ ~ 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 o Information Type (2 bytes): Type of information provided. Defined 457 types are: 459 * Type = 0: String. The Information field contains a free-form 460 UTF-8 string whose length is given by the "Information Length" 461 field. Inclusion of this TLV is optional. It MAY be used to 462 provide further detail for any of the defined reasons. 463 Multiple String TLVs MAY be included in the message. 465 * Type = 1: Reason. The Information field contains a two-byte 466 code indicating the reason the connection was terminated. Some 467 reasons may have further TLVs associated with them. Inclusion 468 of this TLV is REQUIRED. Defined reasons are: 470 + Reason = 0: Session administratively closed. The session 471 might be re-initiated. 473 + Reason = 1: Unspecified reason. 475 + Reason = 2: Out of resources. The router has exhausted 476 resources available for the BMP session. 478 + Reason = 3: Redundant connection. The router has determined 479 that this connection is redundant with another one. 481 + Reason = 4: Session permanently administratively closed, 482 will not be re-initiated. Collector should reduce 483 (potentially to zero) the rate at which it attempts 484 reconnection to the monitored router. 486 o Information Length (2 bytes): The length of the following 487 Information field, in bytes. 489 o Information (variable): Information about the monitored router, 490 according to the type. 492 4.6. Route Monitoring 494 Route Monitoring messages are used for initial synchronization of 495 ADJ-RIBs-In. They are also used for ongoing monitoring of received 496 advertisements and withdraws. Route monitoring messages are state- 497 compressed. This is all discussed in more detail in Section 5. 499 Following the common BMP header and per-peer header is a BGP Update 500 PDU. 502 4.7. Route Mirroring 504 Route Mirroring messages are used for verbatim duplication of 505 messages as received. A possible use for mirroring is exact 506 mirroring of one or more monitored BGP sessions, without state 507 compression. Another possible use is mirroring of messages that have 508 been treated-as-withdraw [I-D.ietf-idr-error-handling], for debugging 509 purposes. Mirrored messages may be sampled, or may provide complete 510 fidelity. The Messages Lost Information code is provided to allow 511 this to be communicated. Section 6 provides more detail. 513 Following the common BMP header and per-peer header is a set of TLVs 514 that contain information about a message or set of messages. Each 515 TLV comprises a two-byte type code, a two-byte length field, and a 516 variable-length value. Inclusion of any given TLV is OPTIONAL, 517 however at least one TLV SHOULD be included, otherwise what's the 518 point of sending the message? Defined TLVs are as follows: 520 o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an 521 Update message. If the BGP Message TLV occurs in the Route 522 Mirroring message, it MUST occur last in the list of TLVs. 524 o Type = 1: Information. A two-byte code that provides information 525 about the mirrored message or message stream. Defined codes are: 527 * Code = 0: Errored PDU. The contained message was found to have 528 some error that made it unusable, causing it to be treated-as- 529 withdraw [I-D.ietf-idr-error-handling]. A BGP Message TLV MUST 530 also occur in the TLV list. 532 * Code = 1: Messages Lost. One or more messages may have been 533 lost. This could occur, for example, if an implementation runs 534 out of available buffer space to queue mirroring messages. 536 4.8. Stats Reports 538 These messages contain information that could be used by the 539 monitoring station to observe interesting events that occur on the 540 router. 542 Transmission of SR messages could be timer triggered or event driven 543 (for example, when a significant event occurs or a threshold is 544 reached). This specification does not impose any timing restrictions 545 on when and on what event these reports have to be transmitted. It 546 is left to the implementation to determine transmission timings -- 547 however, configuration control should be provided of the timer and/or 548 threshold values. This document only specifies the form and content 549 of SR messages. 551 Following the common BMP header and per-peer header is a 4-byte field 552 that indicates the number of counters in the stats message where each 553 counter is encoded as a TLV. 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Stats Count | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Each counter is encoded as follows, 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Stat Type | Stat Len | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Stat Data | 567 ~ ~ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 o Stat Type (2 bytes): Defines the type of the statistic carried in 571 the "Stat Data" field. 573 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 575 This specification defines the following statistics. A BMP 576 implementation MUST ignore unrecognized stat types on receipt, and 577 likewise MUST ignore unexpected data in the Stat Data field. 579 Stats are either counters or gauges, defined as follows after the 580 examples of [RFC1155] Section 3.2.3.3 and [RFC2856] Section 4 581 respectively: 583 32-bit Counter: A non-negative integer which monotonically increases 584 until it reaches a maximum value, when it wraps around and starts 585 increasing again from zero. It has a maximum value of 2^32-1 586 (4294967295 decimal). 588 64-bit Gauge: non-negative integer, which may increase or decrease, 589 but shall never exceed a maximum value, nor fall below a minimum 590 value. The maximum value can not be greater than 2^64-1 591 (18446744073709551615 decimal), and the minimum value can not be 592 smaller than 0. The value has its maximum value whenever the 593 information being modeled is greater than or equal to its maximum 594 value, and has its minimum value whenever the information being 595 modeled is smaller than or equal to its minimum value. If the 596 information being modeled subsequently decreases below (increases 597 above) the maximum (minimum) value, the 64-bit Gauge also decreases 598 (increases). 600 o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by 601 inbound policy. 603 o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix 604 advertisements. 606 o Stat Type = 2: (32-bit Counter) Number of (known) duplicate 607 withdraws. 609 o Stat Type = 3: (32-bit Counter) Number of updates invalidated due 610 to CLUSTER_LIST loop. 612 o Stat Type = 4: (32-bit Counter) Number of updates invalidated due 613 to AS_PATH loop. 615 o Stat Type = 5: (32-bit Counter) Number of updates invalidated due 616 to ORIGINATOR_ID. 618 o Stat Type = 6: (32-bit Counter) Number of updates invalidated due 619 to AS_CONFED loop. 621 o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In. 623 o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. 625 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The 626 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 627 a 64-bit Gauge. 629 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The 630 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 631 a 64-bit Gauge. 633 o Stat Type = 11: (32-bit Counter) Number of updates subjected to 634 treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. 636 o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to 637 treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. 639 o Stat Type = 13: (32-bit Counter) Number of duplicate update 640 messages received. 642 Note that although the current specification only specifies 4-byte 643 counters and 8-byte gauges as "Stat Data", this does not preclude 644 future versions from incorporating more complex TLV-type "Stat Data" 645 (for example, one which can carry prefix specific data). SR messages 646 are optional. However if an SR message is transmitted, at least one 647 statistic MUST be carried in it. 649 4.9. Peer Down Notification 651 This message is used to indicate that a peering session was 652 terminated. 654 0 1 2 3 4 5 6 7 8 655 +-+-+-+-+-+-+-+-+ 656 | 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Data (present if Reason = 1, 2 or 3) | 659 ~ ~ 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Reason indicates why the session was closed. Defined values are: 664 o Reason 1: The local system closed the session. Following the 665 Reason is a BGP PDU containing a BGP NOTIFICATION message that 666 would have been sent to the peer. 668 o Reason 2: The local system closed the session. No notification 669 message was sent. Following the reason code is a two-byte field 670 containing the code corresponding to the FSM Event which caused 671 the system to close the session (see Section 8.1 of [RFC4271]). 672 Two bytes both set to zero are used to indicate that no relevant 673 Event code is defined. 675 o Reason 3: The remote system closed the session with a notification 676 message. Following the Reason is a BGP PDU containing the BGP 677 NOTIFICATION message as received from the peer. 679 o Reason 4: The remote system closed the session without a 680 notification message. 682 o Reason 5: Information for this peer will no longer be sent to the 683 monitoring station for configuration reasons. This does not, 684 strictly speaking, indicate that the peer has gone down, but it 685 does indicate that the monitoring station will not receive updates 686 for the peer. 688 A Peer Down message implicitly withdraws all routes that had been 689 associated with the peer in question. A BMP implementation MAY omit 690 sending explicit withdraws for such routes. 692 4.10. Peer Up Notification 694 The Peer Up message is used to indicate that a peering session has 695 come up (i.e., has transitioned into ESTABLISHED state). Following 696 the common BMP header and per-peer header is the following: 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Local Address (16 bytes) | 701 ~ ~ 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Local Port | Remote Port | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Sent OPEN Message | 706 ~ ~ 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Received OPEN Message | 709 ~ ~ 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Information (variable) | 712 ~ ~ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 o Local Address: The local IP address associated with the peering 716 TCP session. It is 4 bytes long if an IPv4 address is carried in 717 this field, as determined by the V flag (with most significant 718 bytes zero filled) and 16 bytes long if an IPv6 address is carried 719 in this field. 721 o Local Port: The local port number associated with the peering TCP 722 session, or zero if no TCP session actually exists (see 723 Section 8.2). 725 o Remote Port: The remote port number associated with the peering 726 TCP session, or zero if no TCP session actually exists (see 727 Section 8.2). (Note that the remote address can be found in the 728 Peer Address field of the fixed header.) 730 o Sent OPEN Message: The full OPEN message transmitted by the 731 monitored router to its peer. 733 o Received OPEN Message: The full OPEN message received by the 734 monitored router from its peer. 736 o Information: Information about the peer, using the Information TLV 737 (Section 4.4) format. Only the string type is defined in this 738 context; it may be repeated. Inclusion of the Information field 739 is OPTIONAL. Its presence or absence can be inferred by 740 inspection of the Message Length in the common header. 742 5. Route Monitoring 744 In BMP's normal operating mode, after the BMP session is up, Route 745 Monitoring messages are used to provide a snapshot of the Adj-RIB-In 746 of each monitored peer. This is done by sending all routes stored in 747 the Adj-RIB-In of those peers using standard BGP Update messages, 748 encapsulated in Route Monitoring messages. There is no requirement 749 on the ordering of messages in the peer dumps. When the initial dump 750 is completed for a given peer, this MUST be indicated by sending an 751 End-of-RIB marker for that peer (as specified in Section 2 of 752 [RFC4724], plus the BMP encapsulation header). See also Section 9. 754 A BMP speaker may send pre-policy routes, post-policy routes, or 755 both. The selection may be due to implementation constraints (it is 756 possible that a BGP implementation may not store, for example, routes 757 which have been filtered out by policy). Pre-policy routes MUST have 758 their L flag clear in the BMP header (see Section 4), post-policy 759 routes MUST have their L flag set. When an implementation chooses to 760 send both pre- and post-policy routes, it is effectively multiplexing 761 two update streams onto the BMP session. The streams are 762 distinguished by their L flags. 764 If the implementation is able to provide information about when 765 routes were received, it MAY provide such information in the BMP 766 timestamp field. Otherwise, the BMP timestamp field MUST be set to 767 zero, indicating that time is not available. 769 Ongoing monitoring is accomplished by propagating route changes in 770 BGP Update PDUs and forwarding those PDUs to the monitoring station, 771 again using RM messages. When a change occurs to a route, such as an 772 attribute change, the router must update the monitor with the new 773 attribute. As discussed above, it MAY generate either an update with 774 the L flag clear, with it set, or two updates, one with the L flag 775 clear and the other with the L flag set. When a route is withdrawn 776 by a peer, a corresponding withdraw is sent to the monitor. The 777 withdraw MUST have its L flag set to correspond to that of any 778 previous announcement; if the route in question was previously 779 announced with L flag both clear and set, the withdraw MUST similarly 780 be sent twice, with L flag clear and set. Multiple changed routes 781 MAY be grouped into a single BGP UPDATE PDU when feasible, exactly as 782 in the standard BGP protocol. 784 It's important to note that RM messages are not replicated messages 785 received from a peer. While the router should attempt to generate 786 updates as soon as they are received there is a finite time that 787 could elapse between reception of an update and the generation an RM 788 message and its transmission to the monitoring station. If there are 789 state changes in the interim for that prefix, it is acceptable that 790 the router generate the final state of that prefix to the monitoring 791 station. This is sometimes known as "state compression". The actual 792 PDU generated and transmitted to the station might also differ from 793 the exact PDU received from the peer, for example due to differences 794 between how different implementations format path attributes. 796 6. Route Mirroring 798 Route Mirroring messages are provided for two primary reasons: First, 799 to enable an implementation to operate in a mode where it provides a 800 full-fidelity view of all messages received from its peers, without 801 state compression. As we note in Section 5, BMP's normal operational 802 mode cannot provide this. Implementors are strongly cautioned that 803 without state compression, an implementation could require unbounded 804 storage to buffer messages queued to be mirrored. This requirement, 805 and concomitant performance implications, means that this mode of 806 operation is unlikely to be suitable for implementation in 807 conventional routers, and its use is NOT RECOMMENDED except in cases 808 where implementors have carefully considered the tradeoffs. 810 The second application for Route Mirroring is for error reporting and 811 diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router 812 can process BGP messages that are determined to contain errors, 813 without resetting the BGP session. Such messages MAY be mirrored. 814 The buffering used for such mirroring SHOULD be limited. If an 815 errored message is unable to be mirrored due to buffer exhaustion, a 816 message with the "Messages Lost" code SHOULD be sent to indicate 817 this. (This implies that a buffer should be reserved for this use.) 819 7. Stat Reports 821 As outlined above, SR messages are used to monitor specific events 822 and counters on the monitored router. One type of monitoring could 823 be to find out if there are an undue number of route advertisements 824 and withdraws happening (churn) on the monitored router. Another 825 metric is to evaluate the number of looped AS-Paths on the router. 827 While this document proposes a small set of counters to begin with, 828 the authors envision this list may grow in the future with new 829 applications that require BMP style monitoring. 831 8. Other Considerations 833 8.1. Multiple Instances 835 Some routers may support multiple instances of the BGP protocol, for 836 example as "logical routers" or through some other facility. The BMP 837 protocol relates to a single instance of BGP; thus, if a router 838 supports multiple BGP instances it should also support multiple BMP 839 instances (one per BGP instance). 841 8.2. Locally-Originated Routes 843 Some consideration is required for routes that are originated into 844 BGP by the local router, whether as a result of redistribution from a 845 another protocol or for some other reason. 847 Such routes can be modeled as having been sent by the router to 848 itself, placing the router's own address in the Peer Address field of 849 the header. It is RECOMMENDED that when doing so the router should 850 use the same address it has used as its local address for the BMP 851 session. Since in this case no transport session actually exists the 852 Local and Remote Port fields of the Peer Up message MUST be set to 853 zero. Clearly the OPEN Message fields of the Peer Up message will 854 equally not have been physically transmitted, but should represent 855 the relevant capabilities of the local router. 857 Also recall that the L flag is used to indicate locally-sourced 858 routes, see Section 4.2. 860 9. Using BMP 862 Once the BMP session is established route monitoring starts dumping 863 the current snapshot as well as incremental changes simultaneously. 865 It is fine to have these operations occur concurrently. If the 866 initial dump visits a route and subsequently a withdraw is received, 867 this will be forwarded to the monitoring station which would have to 868 correlate and reflect the deletion of that route in its internal 869 state. This is an operation a monitoring station would need to 870 support regardless. 872 If the router receives a withdraw for a prefix even before the peer 873 dump procedure visits that prefix, then the router would clean up 874 that route from its internal state and will not forward it to the 875 monitoring station. In this case, the monitoring station may receive 876 a bogus withdraw which it can safely ignore. 878 10. IANA Considerations 880 IANA is requested to create the following registries. 882 10.1. BMP Message Types 884 This document defines five message types for transferring BGP 885 messages between cooperating systems (Section 4): 887 o Type 0: Route Monitor 888 o Type 1: Statistics Report 889 o Type 2: Peer Down Notification 890 o Type 3: Peer Up Notification 891 o Type 4: Initiation 892 o Type 5: Termination 893 o Type 6: Mirroring 895 Type values 7 through 128 MUST be assigned using the "Standards 896 Action" policy, and values 129 through 255 using the "Specification 897 Required" policy defined in [RFC5226]. 899 10.2. BMP Statistics Types 901 This document defines nine statistics types for statistics reporting 902 (Section 4.8): 904 o Stat Type = 0: Number of prefixes rejected by inbound policy. 905 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 906 o Stat Type = 2: Number of (known) duplicate withdraws. 907 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 908 loop. 909 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 910 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 911 o Stat Type = 6: Number of updates invalidated due to a loop found 912 in AS_CONFED_SEQUENCE or AS_CONFED_SET. 913 o Stat Type = 7: Number of routes in Adj-RIBs-In. 914 o Stat Type = 8: Number of routes in Loc-RIB. 915 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. 916 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. 917 o Stat Type = 11: Number of updates subjected to treat-as-withdraw. 918 o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw. 919 o Stat Type = 13: Number of duplicate update messages received. 921 Stat Type values 14 through 32767 MUST be assigned using the 922 "Standards Action" policy, and values 32768 through 65535 using the 923 "Specification Required" policy, defined in [RFC5226]. 925 10.3. BMP Initiation Message TLVs 927 This document defines three types for information carried in the 928 Initiation message (Section 4.3): 930 o Type = 0: String. 931 o Type = 1: sysDescr. 932 o Type = 2: sysName. 934 Information type values 3 through 32767 MUST be assigned using the 935 "Standards Action" policy, and values 32768 through 65535 using the 936 "Specification Required" policy, defined in [RFC5226]. 938 10.4. BMP Termination Message TLVs 940 This document defines two types for information carried in the 941 Termination message (Section 4.5): 943 o Type = 0: String. 944 o Type = 1: Reason. 946 Information type values 2 through 32767 MUST be assigned using the 947 "Standards Action" policy, and values 32768 through 65535 using the 948 "Specification Required" policy, defined in [RFC5226]. 950 10.5. BMP Termination Message Reason Codes 952 This document defines four types for information carried in the 953 Termination message (Section 4.5) Reason code,: 955 o Type = 0: Administratively closed. 956 o Type = 1: Unspecified reason. 957 o Type = 2: Out of resources. 958 o Type = 3: Redundant connection. 959 o Type = 4: Permanently administratively closed. 961 Information type values 5 through 32767 MUST be assigned using the 962 "Standards Action" policy, and values 32768 through 65535 using the 963 "Specification Required" policy, defined in [RFC5226]. 965 10.6. BMP Peer Down Reason Codes 967 This document defines five types for information carried in the Peer 968 Down Notification (Section 4.9) Reason code: 970 o Type = 1: Local system closed, NOTIFICATION PDU follows. 971 o Type = 2: Local system closed, FSM Event follows. 972 o Type = 3: Remote system closed, NOTIFICATION PDU follows. 973 o Type = 4: Remote system closed, no data. 974 o Type = 5: Peer de-configured. 976 Information type values 6 through 32767 MUST be assigned using the 977 "Standards Action" policy, and values 32768 through 65535 using the 978 "Specification Required" policy, defined in [RFC5226]. Value 0 is 979 reserved. 981 10.7. Route Mirroring TLVs 983 This document defines two types for information carried in the Route 984 Mirroring message (Section 4.7): 986 o Type = 0: BGP Message. 987 o Type = 1: Information. 989 Information type values 2 through 32767 MUST be assigned using the 990 "Standards Action" policy, and values 32768 through 65535 using the 991 "Specification Required" policy, defined in [RFC5226]. 993 10.8. BMP Route Mirroring Information Codes 995 This document defines two types for information carried in the Route 996 Mirroring Information (Section 4.7) code: 998 o Type = 0: Errored PDU. 999 o Type = 1: Messages Lost. 1001 Information type values 2 through 32767 MUST be assigned using the 1002 "Standards Action" policy, and values 32768 through 65535 using the 1003 "Specification Required" policy, defined in [RFC5226]. Value 0 is 1004 reserved. 1006 11. Security Considerations 1008 This document defines a mechanism to obtain a full dump or provide 1009 continuous monitoring of a BGP speaker's local BGP table, including 1010 received BGP messages. This capability could allow an outside party 1011 to obtain information not otherwise obtainable. 1013 Implementations of this protocol MUST require manual configuration of 1014 the monitored and monitoring devices. 1016 Users of this protocol MAY use some type of secure transport 1017 mechanism, such as IPSec [RFC4303] or TCP-AO [RFC5925], in order to 1018 provide mutual authentication, data integrity and transport 1019 protection. 1021 Unless a transport that provides mutual authentication is used, an 1022 attacker could masquerade as the monitored router and trick a 1023 monitoring station into accepting false information. 1025 12. Acknowledgements 1027 Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji 1028 Ioannidis, Mack McBride, Danny McPherson, David Meyer, Dimitri 1029 Papadimitriou, Robert Raszuk, Erik Romijn, and the members of the 1030 GROW working group for their comments. 1032 13. References 1034 13.1. Normative References 1036 [I-D.ietf-idr-error-handling] 1037 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1038 "Revised Error Handling for BGP UPDATE Messages", draft- 1039 ietf-idr-error-handling-19 (work in progress), April 2015. 1041 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1042 for Network Management of TCP/IP-based internets:MIB-II", 1043 STD 17, RFC 1213, March 1991. 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1049 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1051 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1052 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1053 January 2007. 1055 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1056 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1057 May 2008. 1059 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1060 Autonomous System (AS) Number Space", RFC 6793, December 1061 2012. 1063 13.2. Informative References 1065 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 1066 of management information for TCP/IP-based internets", STD 1067 16, RFC 1155, May 1990. 1069 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1070 Conventions for Additional High Capacity Data Types", RFC 1071 2856, June 2000. 1073 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1074 4303, December 2005. 1076 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1077 Authentication Option", RFC 5925, June 2010. 1079 Appendix A. Changes Between BMP Versions 1 and 2 1081 o Added Peer Up Message 1082 o Added L flag 1083 o Editorial changes 1085 Appendix B. Changes Between BMP Versions 2 and 3 1087 o Added a 32-bit length field to the fixed header. 1088 o Clarified error handling. 1089 o Added new stat types: 5 (number of updates invalidated due to 1090 ORIGINATOR_ID), 6 (number of updates invalidated due to 1091 AS_CONFED_SEQUENCE/AS_CONFED_SET), 7 (number of routes in Adj-RIB- 1092 In), 8 (number of routes in Loc-RIB), 9 (number of routes in Adj- 1093 RIB-In, per AFI/SAFI), 10 (numer of routes in Loc-RIB, per AFI/ 1094 SAFI), 11 (number of updates subjected to treat-as-withdraw 1095 treatment), 12 (number of prefixes subjected to treat-as-withdraw 1096 treatment), and 13 (number of duplicate update messages received). 1097 o Defined counters and gauges for use with stat types. 1098 o For peer down messages, the relevant FSM event is to be sent in 1099 type 2 messages. Added type 5 to indicate peer is no longer 1100 monitored. 1101 o Added local address and local and remote ports to the peer up 1102 message. Also optional descriptive string. 1103 o Require End-of-RIB marker after initial dump. 1104 o Added Initiation message with string content. 1105 o Permit multiplexing pre- and post-policy feeds onto a single BMP 1106 session. 1107 o Changed assignment policy for IANA registries. 1108 o Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In", 1109 plus other editorial changes. 1110 o Introduced option for monitoring station to be active party in 1111 initiating connection. 1112 o Introduced Termination message. 1113 o Added "route mirroring" mode. 1114 o Added "A" flag to identify AS Path format in use. 1116 Authors' Addresses 1117 John Scudder 1118 Juniper Networks 1119 1194 N. Mathilda Ave 1120 Sunnyvale, CA 94089 1121 USA 1123 Email: jgs@juniper.net 1125 Rex Fernando 1126 Cisco Systems 1127 170 W. Tasman Dr. 1128 San Jose, CA 95134 1129 USA 1131 Email: rex@cisco.com 1133 Stephen Stuart 1134 Google 1135 1600 Amphitheatre Parkway 1136 Mountain View, CA 94043 1137 USA 1139 Email: sstuart@google.com