idnits 2.17.1 draft-ietf-grow-bmp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2009) is 5246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Scudder 3 Internet-Draft R. Fernando 4 Intended status: Standards Track Juniper Networks 5 Expires: June 17, 2010 S. Stuart 6 Google 7 December 14, 2009 9 BGP Monitoring Protocol 10 draft-ietf-grow-bmp-03 12 Abstract 14 This document proposes a simple protocol, BMP, which can be used to 15 monitor BGP sessions. BMP is intended to provide a more convenient 16 interface for obtaining route views for research purpose than the 17 screen-scraping approach in common use today. The design goals are 18 to keep BMP simple, useful, easily implemented, and minimally 19 service-affecting. BMP is not suitable for use as a routing 20 protocol. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on June 17, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 76 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6 78 2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 79 2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 80 2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8 81 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9 82 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 12 91 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 Many researchers wish to have access to the contents of routers' BGP 97 RIBs as well as a view of protocol updates that the router is 98 receiving. This monitoring task cannot be realized by standard 99 protocol mechanisms. At present, this data can only be obtained 100 through screen-scraping. 102 The BMP protocol provides access to the Adj-RIB-In of a peer on an 103 ongoing basis and a periodic dump of certain statistics that the 104 monitoring station can use for further analysis. The following are 105 the messages provided by BMP. 107 o Route Monitoring (RM): An initial dump of all routes received from 108 a peer as well as an ongoing mechanism that sends the incremental 109 routes advertised and withdrawn by a peer to the monitoring 110 station. 112 o Peer Down Notification (PD): A message sent to indicate that a 113 peering session has gone down with information indicating the 114 reason for the session disconnect. 116 o Stats Reports (SR): This is an ongoing dump of statistics that can 117 be used by the monitoring station as a high level indication of 118 the activity going on in the router. 120 o Peer Up Notification (PU): A message sent to indicate that a 121 peering session has come up. The message includes information 122 regarding the data exchanged between the peers in their OPEN 123 messages as well as information about the peering TCP session 124 itself. 126 BMP operates over TCP. All options are controlled by configuration 127 on the monitored router. No message is ever sent from the monitoring 128 station to the monitored router. The monitored router MAY take steps 129 to prevent the monitoring station from sending data (e.g. by half- 130 closing the TCP session or setting its window size to zero) or it MAY 131 silently discard any data erroneously sent by the monitoring station. 133 The monitoring station is configured to listen on a particular TCP 134 port and the router is configured to establish an active connection 135 to that port and to send messages on that TCP connection. There is 136 no initialization or handshaking phase, messages are simply sent as 137 soon as the connection is established. If the router is unable to 138 connect to the monitoring station, it periodically retries the 139 connection. A suggested default retry period is 30 seconds. 141 If the monitoring station intends to restart BMP processing, it 142 simply drops the connection. The router then re-establishes the 143 connection and resends the messages. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. BMP Message Format 153 The following common header appears in all BMP messages. The rest of 154 the data in a BMP message is dependent on the "Message Type" field in 155 the common header. 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Version | Message Length | Msg. Type | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Peer Type | Peer Flags | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Peer Distinguisher (present based on peer type) | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Peer Address (16 bytes) | 167 ~ ~ 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Peer AS | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Peer BGP ID | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Timestamp (seconds) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Timestamp (microseconds) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 o Version (1 byte): Indicates the BMP version. This is set to '3' 179 for all messages defined in this specification. 181 o Message Length (2 bytes): Length of the message in bytes 182 (including headers, data and encapsulated messages, if any). 184 o Message Type (1 byte): This identifies the type of the BMP 185 message. A BMP implementation MUST ignore unrecognized message 186 types upon receipt. 188 * Type = 0: Route Monitoring 189 * Type = 1: Statistics Report 190 * Type = 2: Peer Down Notification 191 * Type = 3: Peer Up Notification 193 o Peer Type (1 byte): These bits identify the type of the peer. 194 Currently only two types of peers are identified, 196 * Peer Type = 0: Global Instance Peer 197 * Peer Type = 1: L3 VPN Instance Peer 199 o Peer Flags (1 byte): These flags provide more information about 200 the peer. The flags are defined as follows. 202 0 1 2 3 4 5 6 7 8 203 +-+-+-+-+-+-+-+-+ 204 |V|L| Reserved | 205 +-+-+-+-+-+-+-+-+ 207 * The V flag indicates the the Peer address is an IPv6 address. 208 For IPv4 peers this is set to 0. 209 * The L flag, if set to 1, indicates that the message reflects 210 the Loc-RIB (i.e., it reflects the application of inbound 211 policy). It is set to 0 if the message reflects the 212 Adj-RIB-In. 213 * The remaining bits are reserved for future use. 215 o Peer Distinguisher (8 bytes): Routers today can have multiple 216 instances (example L3VPNs). This field is present to distinguish 217 peers that belong to one address domain from the other. 219 If the peer is a "Global Instance Peer", this field is zero 220 filled. If the peer is a "L3VPN Instance Peer", it is set to the 221 route distinguisher of the particular L3VPN instance that the peer 222 belongs to. 224 o Peer Address: The remote IP address associated with the TCP 225 session over which the encapsulated PDU was received. It is 4 226 bytes long if an IPv4 address is carried in this field (with most 227 significant bytes zero filled) and 16 bytes long if an IPv6 228 address is carried in this field. 230 o Peer AS: The Autonomous System number of the peer from which the 231 encapsulated PDU was received. If a 16 bit AS number is stored in 232 this field [RFC4893], it should be padded with zeroes in the most 233 significant bits. 235 o Peer BGP ID: The BGP Identifier of the peer from which the 236 encapsulated PDU was received. 238 o Timestamp: The time when the encapsulated routes were received 239 (one may also think of this as the time when they were installed 240 in the Adj-RIB-In), expressed in seconds and microseconds since 241 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 242 unavailable. Precision of the timestamp is implementation- 243 dependent. 245 2.1. Route Monitoring 247 Route Monitoring messages are used for initial synchronization of 248 ADJ-RIB-In. They are also used for ongoing monitoring of received 249 advertisements and withdraws. This is discussed in more detail in 250 subsequent sections. 252 Following the common BMP header is a BGP PDU. 254 2.2. Stats Reports 256 These messages contain information that could be used by the 257 monitoring station to observe interesting events that occur on the 258 router. 'Stats Report' messages have a message type of '3'. 260 The transmission of the SR messages could be timer triggered or event 261 driven (for example, when a significant event occurs or a threshold 262 is reached). This specification does not impose any timing 263 restrictions on when and on what event these reports have to be 264 transmitted. It is left to the implementation to determine 265 transmission timings -- however, configuration control should be 266 provided of the timer and/or threshold values. This document only 267 specifies the form and content of SR messages. 269 Following the common BMP header is a 4-byte field that indicates the 270 number of counters in the stats message where each counter is encoded 271 as a TLV. 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Stats Count | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Each counter is encoded as follows, 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Stat Type | Stat Len | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Stat Data | 284 ~ ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 o Stat Type (2 bytes): Defines the type of the statistic carried in 288 the "Stat Data" field. 290 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 292 This specification defines the following statistics. All statistics 293 are 4-byte quantities and the stats data are counters. A BMP 294 implementation MUST ignore unrecognized stat types on receipt, and 295 likewise MUST ignore unexpected data in the Stat Data field. 297 o Stat Type = 0: Number of prefixes rejected by inbound policy. 299 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 301 o Stat Type = 2: Number of (known) duplicate withdraws. 303 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 304 loop. 306 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 308 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 310 o Stat Type = 6: Number of updates invalidated due to AS_CONFED 311 loop. 313 Note that the current specification only specifies 4-byte counters as 314 "Stat Data". This does not preclude future versions from 315 incorporating more complex TLV-type "Stat Data" (for example, one 316 which can carry prefix specific data). SR messages are optional. 317 However if an SR message is transmitted, this specification requires 318 at least one statistic to be carried in it. 320 2.3. Peer Down Notification 322 This message is used to indicate that a peering session was 323 terminated. The type of this message is 4. 325 0 1 2 3 4 5 6 7 8 326 +-+-+-+-+-+-+-+-+ 327 | 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Data (present if Reason = 1, 2 or 3) | 330 ~ ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Reason indicates why the session was closed. Defined values are: 335 o Reason 1: The local system closed the session. Following the 336 Reason is a BGP PDU containing a BGP NOTIFICATION message that 337 would have been sent to the peer. 339 o Reason 2: The local system closed the session. No notification 340 message was sent. Following the reason code is a two-byte field 341 containing the code corresponding to the FSM Event which caused 342 the system to close the session (see Section 8.1 of [RFC4271]). 343 Zero is used to indicate that no relevant Event code is defined. 345 o Reason 3: The remote system closed the session with a notification 346 message. Following the Reason is a BGP PDU containing the BGP 347 NOTIFICATION message as received from the peer. 349 o Reason 4: The remote system closed the session without a 350 notification message. 352 2.4. Peer Up Notification 354 The Peer Up message is used to indicate that a peering session has 355 come up (i.e., has transitioned into ESTABLISHED state). Following 356 the common BMP header is the following: 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Local Address (16 bytes) | 361 ~ ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Local Port | Remote Port | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sent OPEN Message | 366 ~ ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Received OPEN Message | 369 ~ ~ 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 o Local Address: The local IP address associated with the peering 373 TCP session. It is 4 bytes long if an IPv4 address is carried in 374 this field, as determined by the V flag (with most significant 375 bytes zero filled) and 16 bytes long if an IPv6 address is carried 376 in this field. 378 o Local Port: The local port number associated with the peering TCP 379 session. 381 o Remote Port: The remote port number associated with the peering 382 TCP session. (Note that the remote address can be found in the 383 Peer Address field of the fixed header.) 385 o Sent OPEN Message: The full OPEN message transmitted by the 386 monitored router to its peer. 388 o Received OPEN Message: The full OPEN message received by the 389 monitored router from its peer. 391 3. Route Monitoring 393 After the BMP session is up, Route Monitoring messages are used to 394 provide a snapshot of the Adj-RIB-In of a particular peer. It does 395 so by sending all routes stored in the Adj-RIB-In of that peer using 396 standard BGP Update messages. There is no requirement on the 397 ordering of messages in the peer dump. 399 Depending on the implementation or configuration, it may only be 400 possible to send the Loc-RIB (post-policy routes) instead of the Adj- 401 RIB-In. This is because it is possible that a BGP implementation may 402 not store, for example, routes which have been filtered out by 403 policy. If this is the case, the implementation may send the Loc-RIB 404 path that pertains to a particular peer in the route monitor message. 406 If the implementation is able to provide information about when 407 routes were received, it MAY provide such information in the BMP 408 timestamp field. Otherwise, the BMP timestamp field MUST be set to 409 zero, indicating that time is not available. 411 Ongoing monitoring is accomplished by propagating route changes in 412 BGP UPDATE PDUs and forwarding those PDUs to the monitoring station, 413 again using RM messages. When a change occurs to a route, such as an 414 attribute change, the router must update the monitor with the new 415 attribute. When a route is withdrawn by a peer, a corresponding 416 withdraw is sent to the monitor. Multiple changed routes MAY be 417 grouped into a single BGP UPDATE PDU when feasible, exactly as in the 418 standard BGP protocol. 420 It's important to note that RM messages are not real time replicated 421 messages received from a peer. While the router should attempt to 422 generate updates as soon as they are received there is a finite time 423 that could elapse between reception of an update and the generation 424 an RM message and its transmission to the monitoring station. If 425 there are state changes in the interim for that prefix, it is 426 acceptable that the router generate the final state of that prefix to 427 the monitoring station. The actual PDU generated and transmitted to 428 the station might also differ from the exact PDU received from the 429 peer, for example due to differences between how different 430 implementations format path attributes. 432 4. Stat Reports 434 As outlined above, SR messages are used to monitor specific events 435 and counters on the monitored router. One type of monitoring could 436 be to find out if there are an undue number of route advertisements 437 and withdraws happening (churn) on the monitored router. Another 438 metric is to evaluate the number of looped AS-Paths on the router. 440 While this document proposes a small set of counters to begin with, 441 the authors envision this list may grow in the future with new 442 applications that require BMP style monitoring. 444 5. Other Considerations 446 Some routers may support multiple instances of the BGP protocol, for 447 example as "logical routers" or through some other facility. The BMP 448 protocol relates to a single instance of BGP; thus, if a router 449 supports multiple BGP instances it should also support multiple BMP 450 instances (one per BMP instance). 452 6. Using BMP 454 Once the BMP session is established route monitoring starts dumping 455 the current snapshot as well as incremental changes simultaneously. 457 It is fine to have these operations occur concurrently. If the 458 initial dump visits a route and subsequently a withdraw is received, 459 this will be forwarded to the monitoring station which would have to 460 correlate and reflect the deletion of that route in its internal 461 state. This is an operation a monitoring station would need to 462 support regardless. 464 If the router receives a withdraw for a prefix even before the peer 465 dump procedure visits that prefix, then the router would clean up 466 that route from its internal state and will not forward it to the 467 monitoring station. In this case, the monitoring station may receive 468 a bogus withdraw which it can safely ignore. 470 7. IANA Considerations 472 This document defines four message types for transferring BGP 473 messages between cooperating systems (Section 2): 475 o Type 0: Route Monitor 476 o Type 1: Statistics Report 477 o Type 2: Peer Down Notification 478 o Type 3: Peer Up Notification 480 Type values 4 through 255 MUST be assigned using the "IETF Consensus" 481 policy defined in [RFC5226]. 483 This document defines five statistics types for statistics reporting 484 (Section 2.2): 486 o Stat Type = 0: Number of prefixes rejected by inbound policy. 487 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 488 o Stat Type = 2: Number of (known) duplicate withdraws. 489 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 490 loop. 491 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 492 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 493 o Stat Type = 6: Number of updates invalidated due to AS_CONFED 494 loop. 496 Stat Type values 7 through 32767 MUST be assigned using the "IETF 497 Consensus" policy, and values 32768 through 65535 using the "First 498 Come First Served" policy, defined in [RFC5226]. 500 8. Security Considerations 502 This document defines a mechanism to obtain a full dump or provide 503 continuous monitoring of a BGP speaker's local BGP table, including 504 received BGP messages. This capability could allow an outside party 505 to obtain information not otherwise obtainable. 507 Implementations of this protocol MUST require manual configuration of 508 the monitored and monitoring devices. 510 Users of this protocol MAY use some type of secure transmission 511 mechanism, such as IPSec [RFC4303], to transmit this data. 513 9. References 515 9.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 521 Protocol 4 (BGP-4)", RFC 4271, January 2006. 523 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 524 Number Space", RFC 4893, May 2007. 526 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 527 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 528 May 2008. 530 9.2. Informative References 532 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 533 RFC 4303, December 2005. 535 Appendix A. Changes Between BMP Versions 1 and 2 537 o Added Peer Up Message 538 o Added L flag 539 o Editorial changes 541 Appendix B. Changes Between BMP Versions 2 and 3 543 o Added a 16-bit length field to the fixed header. 544 o Clarified error handling. 545 o Added stat types 5 and 6 (number of updates invalidated due to 546 ORIGINATOR_ID and AS_CONFED, respectively). 547 o For peer down messages, the relevant FSM event is to be sent in 548 type 2 messages. 549 o Added local address and local and remote ports to the peer up 550 message. 552 Authors' Addresses 554 John Scudder 555 Juniper Networks 556 1194 N. Mathilda Ave 557 Sunnyvale, CA 94089 558 USA 560 Email: jgs@juniper.net 562 Rex Fernando 563 Juniper Networks 564 1194 N. Mathilda Ave 565 Sunnyvale, CA 94089 566 USA 568 Email: rex@juniper.net 570 Stephen Stuart 571 Google 572 1600 Amphitheatre Parkway 573 Mountain View, CA 94043 574 USA 576 Email: sstuart@google.com