idnits 2.17.1 draft-ietf-grow-bmp-10.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 (July 20, 2015) is 3203 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, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Fernando 5 Expires: January 21, 2016 Cisco Systems 6 S. Stuart 7 Google 8 July 20, 2015 10 BGP Monitoring Protocol 11 draft-ietf-grow-bmp-10 13 Abstract 15 This document defines a protocol, BMP, that 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 January 21, 2016. 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 . . . . . . . . . . . . . . . . . . . 19 91 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 92 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 95 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 96 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . 25 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 the router is receiving. 115 This monitoring task cannot be realized by standard protocol 116 mechanisms. Prior to introduction of BMP, this data could only be 117 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 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): Used to provide an initial dump of all 150 routes received from a peer as well as an ongoing mechanism that 151 sends the incremental routes advertised and withdrawn by a peer to 152 the monitoring station. 154 o Peer Down Notification: A message sent to indicate a peering 155 session has gone down with information indicating the reason for 156 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: A message sent to indicate a peering session 163 has come up. The message includes information regarding the data 164 exchanged between the peers in their OPEN messages as well as 165 information about the peering TCP session itself. In addition to 166 being sent whenever a peer transitions to ESTABLISHED state, a 167 Peer Up Notification is sent for each peer in ESTABLISHED state 168 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 end or restart BMP processing, 221 it simply drops the connection, optionally with a Termination 222 message. 224 3.3. Lifecycle of a BMP Session 226 A router is configured to speak BMP to one or more monitoring 227 stations. It MAY be configured to send monitoring information for 228 only a subset of its BGP peers. Otherwise, all BGP peers are assumed 229 to be monitored. 231 A BMP session begins when the active party (either router or 232 management station, as determined by configuration) successfully 233 opens a TCP session (the "BMP session"). Once the session is up, the 234 router begins to send BMP messages. It MUST begin by sending an 235 Initiation message. It subsequently sends a Peer Up message over the 236 BMP session for each of its monitored BGP peers that is in 237 Established state. It follows by sending the contents of its Adj- 238 RIBs-In (pre-policy, post-policy or both, see Section 5) encapsulated 239 in Route Monitoring messages. Once it has sent all the routes for a 240 given peer, it MUST send a End-of-RIB message for that peer; when 241 End-of-RIB has been sent for each monitored peer, the initial table 242 dump has completed. (A monitoring station that wishes only to gather 243 a table dump could close the connection once it has gathered an End- 244 of-RIB or Peer Down message corresponding to each Peer Up message.) 246 Following the initial table dump, the router sends incremental 247 updates encapsulated in Route Monitoring messages. It MAY 248 periodically send Stats Reports or even new Initiation messages, 249 according to configuration. If any new monitored BGP peer becomes 250 Established, a corresponding Peer Up message is sent. If any BGP 251 peers for which Peer Up messages were sent transition out of the 252 Established state, corresponding Peer Down messages are sent. 254 A BMP session ends when the TCP session that carries it is closed for 255 any reason. The router MAY send a Termination message prior to 256 closing the session. 258 4. BMP Message Format 260 4.1. Common Header 262 The following common header appears in all BMP messages. The rest of 263 the data in a BMP message is dependent on the "Message Type" field in 264 the common header. 266 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 267 +-+-+-+-+-+-+-+-+ 268 | Version | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Message Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Msg. Type | 273 +---------------+ 275 o Version (1 byte): Indicates the BMP version. This is set to '3' 276 for all messages defined in this specification. Version 0 is 277 reserved and MUST NOT be sent. 279 o Message Length (4 bytes): Length of the message in bytes 280 (including headers, data and encapsulated messages, if any). 282 o Message Type (1 byte): This identifies the type of the BMP 283 message. A BMP implementation MUST ignore unrecognized message 284 types upon receipt. 286 * Type = 0: Route Monitoring 287 * Type = 1: Statistics Report 288 * Type = 2: Peer Down Notification 289 * Type = 3: Peer Up Notification 290 * Type = 4: Initiation Message 291 * Type = 5: Termination Message 293 4.2. Per-Peer Header 295 The per-peer header follows the common header for most BMP messages. 296 The rest of the data in a BMP message is dependent on the "Message 297 Type" field in the common header. 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Peer Type | Peer Flags | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Peer Distinguisher (present based on peer type) | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Peer Address (16 bytes) | 307 ~ ~ 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Peer AS | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Peer BGP ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Timestamp (seconds) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Timestamp (microseconds) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 o Peer Type (1 byte): Identifies the type of the peer. Currently 319 two types of peers are identified, 321 * Peer Type = 0: Global Instance Peer 322 * Peer Type = 1: L3 VPN Instance Peer 324 o Peer Flags (1 byte): These flags provide more information about 325 the peer. The flags are defined as follows. 327 0 1 2 3 4 5 6 7 8 328 +-+-+-+-+-+-+-+-+ 329 |V|L|A| Reserved| 330 +-+-+-+-+-+-+-+-+ 332 * The V flag indicates the the Peer address is an IPv6 address. 333 For IPv4 peers this is set to 0. 334 * The L flag, if set to 1, indicates the message reflects the 335 post-policy Adj-RIB-In (i.e., its path attributes reflect the 336 application of inbound policy). It is set to 0 if the message 337 reflects the pre-policy Adj-RIB-In. Locally-sourced routes 338 also carry an L flag of 1. See Section 5 for further detail. 339 This flag has no significance when used with route mirroring 340 messages (Section 4.7). 341 * The A flag, if set to 1, indicates the message is formatted 342 using the legacy two-byte AS_PATH format. If set to 0, the 343 message is formatted using the four-byte AS_PATH format 344 [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH 345 information as received from its peer, or it MAY choose to 346 reformat all AS_PATH information into four-byte format 347 regardless of how it was received from the peer. In the latter 348 case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be 349 sent in the BMP UPDATE message. This flag has no significance 350 when used with route mirroring messages (Section 4.7). 351 * The remaining bits are reserved for future use. 353 o Peer Distinguisher (8 bytes): Routers today can have multiple 354 instances (example L3VPNs). This field is present to distinguish 355 peers that belong to one address domain from the other. 357 If the peer is a "Global Instance Peer", this field is zero 358 filled. If the peer is a "L3VPN Instance Peer", it is set to the 359 route distinguisher of the particular L3VPN instance the peer 360 belongs to. 362 o Peer Address: The remote IP address associated with the TCP 363 session over which the encapsulated PDU was received. It is 4 364 bytes long if an IPv4 address is carried in this field (with the 365 12 most significant bytes zero-filled) and 16 bytes long if an 366 IPv6 address is carried in this field. 368 o Peer AS: The Autonomous System number of the peer from which the 369 encapsulated PDU was received. If a 16 bit AS number is stored in 370 this field [RFC6793], it should be padded with zeroes in the 16 371 most significant bits. 373 o Peer BGP ID: The BGP Identifier of the peer from which the 374 encapsulated PDU was received. 376 o Timestamp: The time when the encapsulated routes were received 377 (one may also think of this as the time when they were installed 378 in the Adj-RIB-In), expressed in seconds and microseconds since 379 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 380 unavailable. Precision of the timestamp is implementation- 381 dependent. 383 4.3. Initiation Message 385 The initiation message provides a means for the monitored router to 386 inform the monitoring station of its vendor, software version, and so 387 on. An initiation message MUST be sent as the first message after 388 the TCP session comes up. An initiation message MAY be sent at any 389 point thereafter, if warranted by a change on the monitored router. 391 The initiation message consists of the common BMP header followed by 392 two or more Information TLVs (Section 4.4) containing information 393 about the monitored router. The sysDescr and sysName Information 394 TLVs MUST be sent, any others are optional. The string TLV MAY be 395 included multiple times. 397 4.4. Information TLV 399 The Information TLV is used by the Initiation (Section 4.3) and Peer 400 Up (Section 4.10) messages. 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Information Type | Information Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Information (variable) | 407 ~ ~ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 o Information Type (2 bytes): Type of information provided. Defined 411 types are: 413 * Type = 0: String. The Information field contains a free-form 414 UTF-8 string whose length is given by the "Information Length" 415 field. The value is administratively assigned. There is no 416 requirement to terminate the string with a null (or any other 417 particular) character -- the length field gives its 418 termination. If multiple strings are included, their ordering 419 MUST be preserved when they are reported. 421 * Type = 1: sysDescr. The Information field contains an ASCII 422 string whose value MUST be set to be equal to the value of the 423 sysDescr MIB-II [RFC1213] object. 425 * Type = 2: sysName. The Information field contains a ASCII 426 string whose value MUST be set to be equal to the value of the 427 sysName MIB-II [RFC1213] object. 429 o Information Length (2 bytes): The length of the following 430 Information field, in bytes. 432 o Information (variable): Information about the monitored router, 433 according to the type. 435 4.5. Termination Message 437 The termination message provides a way for a monitored router to 438 indicate why it is terminating a session. Although use of this 439 message is RECOMMENDED, a monitoring station must always be prepared 440 for the session to terminate with no message. Once the router has 441 sent a termination message, it MUST close the TCP session without 442 sending any further messages. Likewise, the monitoring station MUST 443 close the TCP session after receiving a termination message. 445 The termination message consists of the common BMP header followed by 446 one or more TLVs containing information about the reason for the 447 termination, as follows: 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Information Type | Information Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Information (variable) | 454 ~ ~ 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 o Information Type (2 bytes): Type of information provided. Defined 458 types are: 460 * Type = 0: String. The Information field contains a free-form 461 UTF-8 string whose length is given by the "Information Length" 462 field. Inclusion of this TLV is optional. It MAY be used to 463 provide further detail for any of the defined reasons. 464 Multiple String TLVs MAY be included in the message. 466 * Type = 1: Reason. The Information field contains a two-byte 467 code indicating the reason the connection was terminated. Some 468 reasons may have further TLVs associated with them. Inclusion 469 of this TLV is REQUIRED. Defined reasons are: 471 + Reason = 0: Session administratively closed. The session 472 might be re-initiated. 474 + Reason = 1: Unspecified reason. 476 + Reason = 2: Out of resources. The router has exhausted 477 resources available for the BMP session. 479 + Reason = 3: Redundant connection. The router has determined 480 this connection is redundant with another one. 482 + Reason = 4: Session permanently administratively closed, 483 will not be re-initiated. Monitoring station should reduce 484 (potentially to zero) the rate at which it attempts 485 reconnection to the monitored router. 487 o Information Length (2 bytes): The length of the following 488 Information field, in bytes. 490 o Information (variable): Information about the monitored router, 491 according to the type. 493 4.6. Route Monitoring 495 Route Monitoring messages are used for initial synchronization of 496 ADJ-RIBs-In. They are also used for ongoing monitoring of ADJ-RIB-In 497 state. Route monitoring messages are state-compressed. This is all 498 discussed in more detail in Section 5. 500 Following the common BMP header and per-peer header is a BGP Update 501 PDU. 503 4.7. Route Mirroring 505 Route Mirroring messages are used for verbatim duplication of 506 messages as received. A possible use for mirroring is exact 507 mirroring of one or more monitored BGP sessions, without state 508 compression. Another possible use is mirroring of messages that have 509 been treated-as-withdraw [I-D.ietf-idr-error-handling], for debugging 510 purposes. Mirrored messages may be sampled, or may be lossless. The 511 Messages Lost Information code is provided to allow losses to be 512 indicated. Section 6 provides more detail. 514 Following the common BMP header and per-peer header is a set of TLVs 515 that contain information about a message or set of messages. Each 516 TLV comprises a two-byte type code, a two-byte length field, and a 517 variable-length value. Inclusion of any given TLV is OPTIONAL, 518 however at least one TLV SHOULD be included, otherwise what's the 519 point of sending the message? Defined TLVs are as follows: 521 o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an 522 Update message. If the BGP Message TLV occurs in the Route 523 Mirroring message, it MUST occur last in the list of TLVs. 525 o Type = 1: Information. A two-byte code that provides information 526 about the mirrored message or message stream. Defined codes are: 528 * Code = 0: Errored PDU. The contained message was found to have 529 some error that made it unusable, causing it to be treated-as- 530 withdraw [I-D.ietf-idr-error-handling]. A BGP Message TLV MUST 531 also occur in the TLV list. 533 * Code = 1: Messages Lost. One or more messages may have been 534 lost. This could occur, for example, if an implementation runs 535 out of available buffer space to queue mirroring messages. 537 4.8. Stats Reports 539 These messages contain information that could be used by the 540 monitoring station to observe interesting events that occur on the 541 router. 543 Transmission of SR messages could be timer triggered or event driven 544 (for example, when a significant event occurs or a threshold is 545 reached). This specification does not impose any timing restrictions 546 on when and on what event these reports have to be transmitted. It 547 is left to the implementation to determine transmission timings -- 548 however, configuration control should be provided of the timer and/or 549 threshold values. This document only specifies the form and content 550 of SR messages. 552 Following the common BMP header and per-peer header is a 4-byte field 553 that indicates the number of counters in the stats message where each 554 counter is encoded as a TLV. 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Stats Count | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Each counter is encoded as follows, 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Stat Type | Stat Len | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Stat Data | 568 ~ ~ 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 o Stat Type (2 bytes): Defines the type of the statistic carried in 572 the "Stat Data" field. 574 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 576 This specification defines the following statistics. A BMP 577 implementation MUST ignore unrecognized stat types on receipt, and 578 likewise MUST ignore unexpected data in the Stat Data field. 580 Stats are either counters or gauges, defined as follows after the 581 examples of [RFC1155] Section 3.2.3.3 and [RFC2856] Section 4 582 respectively: 584 32-bit Counter: A non-negative integer which monotonically increases 585 until it reaches a maximum value, when it wraps around and starts 586 increasing again from zero. It has a maximum value of 2^32-1 587 (4294967295 decimal). 589 64-bit Gauge: non-negative integer, which may increase or decrease, 590 but shall never exceed a maximum value, nor fall below a minimum 591 value. The maximum value can not be greater than 2^64-1 592 (18446744073709551615 decimal), and the minimum value can not be 593 smaller than 0. The value has its maximum value whenever the 594 information being modeled is greater than or equal to its maximum 595 value, and has its minimum value whenever the information being 596 modeled is smaller than or equal to its minimum value. If the 597 information being modeled subsequently decreases below (increases 598 above) the maximum (minimum) value, the 64-bit Gauge also decreases 599 (increases). 601 o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by 602 inbound policy. 604 o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix 605 advertisements. 607 o Stat Type = 2: (32-bit Counter) Number of (known) duplicate 608 withdraws. 610 o Stat Type = 3: (32-bit Counter) Number of updates invalidated due 611 to CLUSTER_LIST loop. 613 o Stat Type = 4: (32-bit Counter) Number of updates invalidated due 614 to AS_PATH loop. 616 o Stat Type = 5: (32-bit Counter) Number of updates invalidated due 617 to ORIGINATOR_ID. 619 o Stat Type = 6: (32-bit Counter) Number of updates invalidated due 620 to AS_CONFED loop. 622 o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In. 624 o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. 626 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The 627 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 628 a 64-bit Gauge. 630 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The 631 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 632 a 64-bit Gauge. 634 o Stat Type = 11: (32-bit Counter) Number of updates subjected to 635 treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. 637 o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to 638 treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. 640 o Stat Type = 13: (32-bit Counter) Number of duplicate update 641 messages received. 643 Although the current specification only specifies 4-byte counters and 644 8-byte gauges as "Stat Data", this does not preclude future versions 645 from incorporating more complex TLV-type "Stat Data" (for example, 646 one that can carry prefix specific data). SR messages are optional. 647 However if an SR message is transmitted, at least one statistic MUST 648 be carried in it. 650 4.9. Peer Down Notification 652 This message is used to indicate a peering session was 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 that caused the 671 system to close the session (see Section 8.1 of [RFC4271]). Two 672 bytes both set to zero are used to indicate no relevant Event code 673 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. This includes any unexpected termination of 681 the transport session, so in some cases both the local and remote 682 systems might consider this to apply. 684 o Reason 5: Information for this peer will no longer be sent to the 685 monitoring station for configuration reasons. This does not, 686 strictly speaking, indicate the peer has gone down, but it does 687 indicate the monitoring station will not receive updates for the 688 peer. 690 A Peer Down message implicitly withdraws all routes that had been 691 associated with the peer in question. A BMP implementation MAY omit 692 sending explicit withdraws for such routes. 694 4.10. Peer Up Notification 696 The Peer Up message is used to indicate a peering session has come up 697 (i.e., has transitioned into ESTABLISHED state). Following the 698 common BMP header and per-peer header is the following: 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Local Address (16 bytes) | 703 ~ ~ 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Local Port | Remote Port | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Sent OPEN Message | 708 ~ ~ 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Received OPEN Message | 711 ~ ~ 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Information (variable) | 714 ~ ~ 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 o Local Address: The local IP address associated with the peering 718 TCP session. It is 4 bytes long if an IPv4 address is carried in 719 this field, as determined by the V flag (with the 12 most 720 significant bytes zero-filled) and 16 bytes long if an IPv6 721 address is carried in this field. 723 o Local Port: The local port number associated with the peering TCP 724 session, or zero if no TCP session actually exists (see 725 Section 8.2). 727 o Remote Port: The remote port number associated with the peering 728 TCP session, or zero if no TCP session actually exists (see 729 Section 8.2). (The remote address can be found in the Peer 730 Address field of the fixed header.) 732 o Sent OPEN Message: The full OPEN message transmitted by the 733 monitored router to its peer. 735 o Received OPEN Message: The full OPEN message received by the 736 monitored router from its peer. 738 o Information: Information about the peer, using the Information TLV 739 (Section 4.4) format. Only the string type is defined in this 740 context; it may be repeated. Inclusion of the Information field 741 is OPTIONAL. Its presence or absence can be inferred by 742 inspection of the Message Length in the common header. 744 5. Route Monitoring 746 In BMP's normal operating mode, after the BMP session is up, Route 747 Monitoring messages are used to provide a snapshot of the Adj-RIB-In 748 of each monitored peer. This is done by sending all routes stored in 749 the Adj-RIB-In of those peers using standard BGP Update messages, 750 encapsulated in Route Monitoring messages. There is no requirement 751 on the ordering of messages in the peer dumps. When the initial dump 752 is completed for a given peer, this MUST be indicated by sending an 753 End-of-RIB marker for that peer (as specified in Section 2 of 754 [RFC4724], plus the BMP encapsulation header). See also Section 9. 756 A BMP speaker may send pre-policy routes, post-policy routes, or 757 both. The selection may be due to implementation constraints (it is 758 possible a BGP implementation may not store, for example, routes that 759 have been filtered out by policy). Pre-policy routes MUST have their 760 L flag clear in the BMP header (see Section 4), post-policy routes 761 MUST have their L flag set. When an implementation chooses to send 762 both pre- and post-policy routes, it is effectively multiplexing two 763 update streams onto the BMP session. The streams are distinguished 764 by their L flags. 766 If the implementation is able to provide information about when 767 routes were received, it MAY provide such information in the BMP 768 timestamp field. Otherwise, the BMP timestamp field MUST be set to 769 zero, indicating time is not available. 771 Ongoing monitoring is accomplished by propagating route changes in 772 BGP Update PDUs and forwarding those PDUs to the monitoring station, 773 again using RM messages. When a change occurs to a route, such as an 774 attribute change, the router must update the monitoring station with 775 the new attribute. As discussed above, it MAY generate either an 776 update with the L flag clear, with it set, or two updates, one with 777 the L flag clear and the other with the L flag set. When a route is 778 withdrawn by a peer, a corresponding withdraw is sent to the 779 monitoring station. The withdraw MUST have its L flag set to 780 correspond to that of any previous announcement; if the route in 781 question was previously announced with L flag both clear and set, the 782 withdraw MUST similarly be sent twice, with L flag clear and set. 783 Multiple changed routes MAY be grouped into a single BGP UPDATE PDU 784 when feasible, exactly as in the standard BGP protocol. 786 It's important to note RM messages are not replicated messages 787 received from a peer. (Route mirroring (Section 6) is provided if 788 this is required.) While the router should attempt to generate 789 updates promptly there is a finite time that could elapse between 790 reception of an update, the generation an RM message, and its 791 transmission to the monitoring station. If there are state changes 792 in the interim for that prefix, it is acceptable that the router 793 generate the final state of that prefix to the monitoring station. 794 This is sometimes known as "state compression". The actual PDU 795 generated and transmitted to the station might also differ from the 796 exact PDU received from the peer, for example due to differences 797 between how different implementations format path attributes. 799 6. Route Mirroring 801 Route Mirroring messages are provided for two primary reasons: First, 802 to enable an implementation to operate in a mode where it provides a 803 full-fidelity view of all messages received from its peers, without 804 state compression. As we note in Section 5, BMP's normal operational 805 mode cannot provide this. Implementors are strongly cautioned that 806 without state compression, an implementation could require unbounded 807 storage to buffer messages queued to be mirrored. Route Mirroring is 808 unlikely to be suitable for implementation in conventional routers, 809 and its use is NOT RECOMMENDED except in cases where implementors 810 have carefully considered the tradeoffs. These tradeoffs include: 811 router resource exhaustion, the potential to flow-block BGP peers, 812 and the slowing of routing convergence. 814 The second application for Route Mirroring is for error reporting and 815 diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router 816 can process BGP messages that are determined to contain errors, 817 without resetting the BGP session. Such messages MAY be mirrored. 818 The buffering used for such mirroring SHOULD be limited. If an 819 errored message is unable to be mirrored due to buffer exhaustion, a 820 message with the "Messages Lost" code SHOULD be sent to indicate 821 this. (This implies a buffer should be reserved for this use.) 823 7. Stat Reports 825 As outlined above, SR messages are used to monitor specific events 826 and counters on the monitored router. One type of monitoring could 827 be to find out if there are an undue number of route advertisements 828 and withdraws happening (churn) on the monitored router. Another 829 metric is to evaluate the number of looped AS-Paths on the router. 831 While this document proposes a small set of counters to begin with, 832 the authors envision this list may grow in the future with new 833 applications that require BMP-style monitoring. 835 8. Other Considerations 836 8.1. Multiple Instances 838 Some routers may support multiple instances of the BGP protocol, for 839 example as "logical routers" or through some other facility. The BMP 840 protocol relates to a single instance of BGP; thus, if a router 841 supports multiple BGP instances it should also support multiple BMP 842 instances (one per BGP instance). 844 8.2. Locally-Originated Routes 846 Some consideration is required for routes originated into BGP by the 847 local router, whether as a result of redistribution from a another 848 protocol or for some other reason. 850 Such routes can be modeled as having been sent by the router to 851 itself, placing the router's own address in the Peer Address field of 852 the header. It is RECOMMENDED that when doing so the router should 853 use the same address it has used as its local address for the BMP 854 session. Since in this case no transport session actually exists the 855 Local and Remote Port fields of the Peer Up message MUST be set to 856 zero. Clearly the OPEN Message fields of the Peer Up message will 857 equally not have been physically transmitted, but should represent 858 the relevant capabilities of the local router. 860 Also recall the L flag is used to indicate locally-sourced routes, 861 see Section 4.2. 863 9. Using BMP 865 Once the BMP session is established route monitoring starts dumping 866 the current snapshot as well as incremental changes simultaneously. 868 It is fine to have these operations occur concurrently. If the 869 initial dump visits a route and subsequently a withdraw is received, 870 this will be forwarded to the monitoring station that would have to 871 correlate and reflect the deletion of that route in its internal 872 state. This is an operation a monitoring station would need to 873 support regardless. 875 If the router receives a withdraw for a prefix even before the peer 876 dump procedure visits that prefix, then the router would clean up 877 that route from its internal state and will not forward it to the 878 monitoring station. In this case, the monitoring station may receive 879 a bogus withdraw it can safely ignore. 881 10. IANA Considerations 883 IANA is requested to create the registries for the following BMP 884 parameters. 886 10.1. BMP Message Types 888 This document defines five message types for transferring BGP 889 messages between cooperating systems (Section 4): 891 o Type 0: Route Monitor 892 o Type 1: Statistics Report 893 o Type 2: Peer Down Notification 894 o Type 3: Peer Up Notification 895 o Type 4: Initiation 896 o Type 5: Termination 897 o Type 6: Mirroring 899 Type values 7 through 128 MUST be assigned using the "Standards 900 Action" policy, and values 129 through 250 using the "Specification 901 Required" policy defined in [RFC5226]. Values 251 through 254 are 902 "Experimental" and value 255 is reserved. 904 10.2. BMP Statistics Types 906 This document defines nine statistics types for statistics reporting 907 (Section 4.8): 909 o Stat Type = 0: Number of prefixes rejected by inbound policy. 910 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 911 o Stat Type = 2: Number of (known) duplicate withdraws. 912 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 913 loop. 914 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 915 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 916 o Stat Type = 6: Number of updates invalidated due to a loop found 917 in AS_CONFED_SEQUENCE or AS_CONFED_SET. 918 o Stat Type = 7: Number of routes in Adj-RIBs-In. 919 o Stat Type = 8: Number of routes in Loc-RIB. 920 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. 921 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. 922 o Stat Type = 11: Number of updates subjected to treat-as-withdraw. 923 o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw. 924 o Stat Type = 13: Number of duplicate update messages received. 926 Stat Type values 14 through 32767 MUST be assigned using the 927 "Standards Action" policy, and values 32768 through 65530 using the 928 "Specification Required" policy, defined in [RFC5226]. Values 65531 929 through 65534 are "Experimental" and value 65535 is reserved. 931 10.3. BMP Initiation Message TLVs 933 This document defines three types for information carried in the 934 Initiation message (Section 4.3): 936 o Type = 0: String. 937 o Type = 1: sysDescr. 938 o Type = 2: sysName. 940 Information type values 3 through 32767 MUST be assigned using the 941 "Standards Action" policy, and values 32768 through 65530 using the 942 "Specification Required" policy, defined in [RFC5226]. Values 65531 943 through 65534 are "Experimental" and value 65535 is reserved. 945 10.4. BMP Termination Message TLVs 947 This document defines two types for information carried in the 948 Termination message (Section 4.5): 950 o Type = 0: String. 951 o Type = 1: Reason. 953 Information type values 2 through 32767 MUST be assigned using the 954 "Standards Action" policy, and values 32768 through 65530 using the 955 "Specification Required" policy, defined in [RFC5226]. Values 65531 956 through 65534 are "Experimental" and value 65535 is reserved. 958 10.5. BMP Termination Message Reason Codes 960 This document defines four types for information carried in the 961 Termination message (Section 4.5) Reason code,: 963 o Type = 0: Administratively closed. 964 o Type = 1: Unspecified reason. 965 o Type = 2: Out of resources. 966 o Type = 3: Redundant connection. 967 o Type = 4: Permanently administratively closed. 969 Information type values 5 through 32767 MUST be assigned using the 970 "Standards Action" policy, and values 32768 through 65530 using the 971 "Specification Required" policy, defined in [RFC5226]. Values 65531 972 through 65534 are "Experimental" and value 65535 is reserved. 974 10.6. BMP Peer Down Reason Codes 976 This document defines five types for information carried in the Peer 977 Down Notification (Section 4.9) Reason code: 979 o Type = 1: Local system closed, NOTIFICATION PDU follows. 980 o Type = 2: Local system closed, FSM Event follows. 981 o Type = 3: Remote system closed, NOTIFICATION PDU follows. 982 o Type = 4: Remote system closed, no data. 983 o Type = 5: Peer de-configured. 985 Information type values 6 through 32767 MUST be assigned using the 986 "Standards Action" policy, and values 32768 through 65530 using the 987 "Specification Required" policy, defined in [RFC5226]. Values 65531 988 through 65534 are "Experimental" and values 0 and 65535 are reserved. 990 10.7. Route Mirroring TLVs 992 This document defines two types for information carried in the Route 993 Mirroring message (Section 4.7): 995 o Type = 0: BGP Message. 996 o Type = 1: Information. 998 Information type values 2 through 32767 MUST be assigned using the 999 "Standards Action" policy, and values 32768 through 65530 using the 1000 "Specification Required" policy, defined in [RFC5226]. Values 65531 1001 through 65534 are "Experimental" and value 65535 is reserved. 1003 10.8. BMP Route Mirroring Information Codes 1005 This document defines two types for information carried in the Route 1006 Mirroring Information (Section 4.7) code: 1008 o Type = 0: Errored PDU. 1009 o Type = 1: Messages Lost. 1011 Information type values 2 through 32767 MUST be assigned using the 1012 "Standards Action" policy, and values 32768 through 65530 using the 1013 "Specification Required" policy, defined in [RFC5226]. Values 65531 1014 through 65534 are "Experimental" and value 65535 is reserved. 1016 11. Security Considerations 1018 This document defines a mechanism to obtain a full dump or provide 1019 continuous monitoring of a BGP speaker's local BGP table, including 1020 received BGP messages. This capability could allow an outside party 1021 to obtain information not otherwise obtainable. 1023 Implementations of this protocol MUST require manual configuration of 1024 the monitored and monitoring devices. 1026 Users of this protocol MAY use some type of secure transport 1027 mechanism, such as IPSec [RFC4303] or TCP-AO [RFC5925], in order to 1028 provide mutual authentication, data integrity and transport 1029 protection. 1031 Unless a transport that provides mutual authentication is used, an 1032 attacker could masquerade as the monitored router and trick a 1033 monitoring station into accepting false information. 1035 12. Acknowledgements 1037 Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji 1038 Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer, 1039 Dimitri Papadimitriou, Robert Raszuk, Erik Romijn, and the members of 1040 the GROW working group for their comments. 1042 13. References 1044 13.1. Normative References 1046 [I-D.ietf-idr-error-handling] 1047 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1048 "Revised Error Handling for BGP UPDATE Messages", draft- 1049 ietf-idr-error-handling-19 (work in progress), April 2015. 1051 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1052 for Network Management of TCP/IP-based internets: MIB-II", 1053 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 1054 . 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, March 1997. 1059 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1060 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1062 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1063 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1064 DOI 10.17487/RFC4724, January 2007, 1065 . 1067 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1068 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1069 DOI 10.17487/RFC5226, May 2008, 1070 . 1072 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1073 Autonomous System (AS) Number Space", RFC 6793, 1074 DOI 10.17487/RFC6793, December 2012, 1075 . 1077 13.2. Informative References 1079 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 1080 of management information for TCP/IP-based internets", 1081 STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, 1082 . 1084 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1085 Conventions for Additional High Capacity Data Types", 1086 RFC 2856, DOI 10.17487/RFC2856, June 2000, 1087 . 1089 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1090 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1091 . 1093 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1094 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1095 June 2010, . 1097 Appendix A. Changes Between BMP Versions 1 and 2 1099 o Added Peer Up Message 1100 o Added L flag 1101 o Editorial changes 1103 Appendix B. Changes Between BMP Versions 2 and 3 1105 o Added a 32-bit length field to the fixed header. 1106 o Clarified error handling. 1107 o Added new stat types: 5 (number of updates invalidated due to 1108 ORIGINATOR_ID), 6 (number of updates invalidated due to 1109 AS_CONFED_SEQUENCE/AS_CONFED_SET), 7 (number of routes in Adj-RIB- 1110 In), 8 (number of routes in Loc-RIB), 9 (number of routes in Adj- 1111 RIB-In, per AFI/SAFI), 10 (numer of routes in Loc-RIB, per AFI/ 1112 SAFI), 11 (number of updates subjected to treat-as-withdraw 1113 treatment), 12 (number of prefixes subjected to treat-as-withdraw 1114 treatment), and 13 (number of duplicate update messages received). 1115 o Defined counters and gauges for use with stat types. 1116 o For peer down messages, the relevant FSM event is to be sent in 1117 type 2 messages. Added type 5 to indicate peer is no longer 1118 monitored. 1120 o Added local address and local and remote ports to the peer up 1121 message. Also optional descriptive string. 1122 o Require End-of-RIB marker after initial dump. 1123 o Added Initiation message with string content. 1124 o Permit multiplexing pre- and post-policy feeds onto a single BMP 1125 session. 1126 o Changed assignment policy for IANA registries. 1127 o Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In", 1128 plus other editorial changes. 1129 o Introduced option for monitoring station to be active party in 1130 initiating connection. 1131 o Introduced Termination message. 1132 o Added "route mirroring" mode. 1133 o Added "A" flag to identify AS Path format in use. 1135 Authors' Addresses 1137 John Scudder (editor) 1138 Juniper Networks 1139 1194 N. Mathilda Ave 1140 Sunnyvale, CA 94089 1141 USA 1143 Email: jgs@juniper.net 1145 Rex Fernando 1146 Cisco Systems 1147 170 W. Tasman Dr. 1148 San Jose, CA 95134 1149 USA 1151 Email: rex@cisco.com 1153 Stephen Stuart 1154 Google 1155 1600 Amphitheatre Parkway 1156 Mountain View, CA 94043 1157 USA 1159 Email: sstuart@google.com