--- 1/draft-ietf-grow-bmp-08.txt 2015-07-04 09:37:51.187661623 -0700 +++ 2/draft-ietf-grow-bmp-09.txt 2015-07-04 09:37:51.447667936 -0700 @@ -1,25 +1,25 @@ -Network Working Group J. Scudder +Network Working Group J. Scudder, Ed. Internet-Draft Juniper Networks Intended status: Standards Track R. Fernando -Expires: November 23, 2015 Cisco Systems +Expires: January 5, 2016 Cisco Systems S. Stuart Google - May 22, 2015 + July 4, 2015 BGP Monitoring Protocol - draft-ietf-grow-bmp-08 + draft-ietf-grow-bmp-09 Abstract - This document defines a protocol, BMP, which can be used to monitor + This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen- scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service- affecting. BMP is not suitable for use as a routing protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 23, 2015. + This Internet-Draft will expire on January 5, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,52 +79,52 @@ 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 - 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 18 + 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 + 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 - 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 20 + 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 - 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 21 + 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 10.7. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 22 10.8. BMP Route Mirroring Information Codes . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 13.2. Informative References . . . . . . . . . . . . . . . . . 23 + 13.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 24 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Many researchers wish to have access to the contents of routers' BGP - RIBs as well as a view of protocol updates that the router is - receiving. This monitoring task cannot be realized by standard - protocol mechanisms. Prior to introduction of BMP, this data could - only be obtained through screen-scraping. + RIBs as well as a view of protocol updates the router is receiving. + This monitoring task cannot be realized by standard protocol + mechanisms. Prior to introduction of BMP, this data could only be + obtained through screen-scraping. The BMP protocol provides access to the Adj-RIB-In of a peer on an - ongoing basis and a periodic dump of certain statistics that the + ongoing basis and a periodic dump of certain statistics the monitoring station can use for further analysis. From a high level, BMP can be thought of as the result of multiplexing together the messages received on the various monitored BGP sessions. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. @@ -139,40 +139,40 @@ o Post-Policy Adj-RIB-In: The result of applying inbound policy to an Adj-RIB-In, but prior to the application of route selection to form the Loc-RIB. 3. Overview of BMP Operation 3.1. BMP Messages The following are the messages provided by BMP. - o Route Monitoring (RM): An initial dump of all routes received from - a peer as well as an ongoing mechanism that sends the incremental - routes advertised and withdrawn by a peer to the monitoring - station. + o Route Monitoring (RM): Used to provide an initial dump of all + routes received from a peer as well as an ongoing mechanism that + sends the incremental routes advertised and withdrawn by a peer to + the monitoring station. - o Peer Down Notification (PD): A message sent to indicate that a - peering session has gone down with information indicating the - reason for the session disconnect. + o Peer Down Notification: A message sent to indicate a peering + session has gone down with information indicating the reason for + the session disconnect. o Stats Reports (SR): An ongoing dump of statistics that can be used by the monitoring station as a high level indication of the activity going on in the router. - o Peer Up Notification (PU): A message sent to indicate that a - peering session has come up. The message includes information - regarding the data exchanged between the peers in their OPEN - messages as well as information about the peering TCP session - itself. In addition to being sent whenever a peer transitions to - ESTABLISHED state, a Peer Up Notification is sent for each peer - that is in ESTABLISHED state when the BMP session itself comes up. + o Peer Up Notification: A message sent to indicate a peering session + has come up. The message includes information regarding the data + exchanged between the peers in their OPEN messages as well as + information about the peering TCP session itself. In addition to + being sent whenever a peer transitions to ESTABLISHED state, a + Peer Up Notification is sent for each peer in ESTABLISHED state + when the BMP session itself comes up. o Initiation: A means for the monitored router to inform the monitoring station of its vendor, software version, and so on. o Termination: A means for the monitored router to inform the monitoring station of why it is closing a BMP session. o Route Mirroring: a means for the monitored router to send verbatim duplicates of messages as received. Can be used to exactly mirror a monitored BGP session. Can also be used to report malformed BGP @@ -210,50 +210,51 @@ A router (or management station) MAY implement logic to detect redundant connections, as might occur if both parties are configured to be active, and MAY elect to terminate redundant connections. A Termination reason code is defined for this purpose. Once a connection is established, the router sends messages over it. There is no initialization or handshaking phase, messages are simply sent as soon as the connection is established. - If the monitoring station intends to restart BMP processing, it - simply drops the connection, optionally with a Termination message. + If the monitoring station intends to end or restart BMP processing, + it simply drops the connection, optionally with a Termination + message. 3.3. Lifecycle of a BMP Session - A router is configured to speak BMP with one or more monitoring + A router is configured to speak BMP to one or more monitoring stations. It MAY be configured to send monitoring information for only a subset of its BGP peers. Otherwise, all BGP peers are assumed to be monitored. A BMP session begins when the active party (either router or management station, as determined by configuration) successfully opens a TCP session (the "BMP session"). Once the session is up, the router begins to send BMP messages. It MUST begin by sending an Initiation message. It subsequently sends a Peer Up message over the - BMP session for each of its monitored BGP peers which are in + BMP session for each of its monitored BGP peers that is in Established state. It follows by sending the contents of its Adj- RIBs-In (pre-policy, post-policy or both, see Section 5) encapsulated in Route Monitoring messages. Once it has sent all the routes for a given peer, it MUST send a End-of-RIB message for that peer; when End-of-RIB has been sent for each monitored peer, the initial table dump has completed. (A monitoring station that wishes only to gather a table dump could close the connection once it has gathered an End- of-RIB or Peer Down message corresponding to each Peer Up message.) Following the initial table dump, the router sends incremental updates encapsulated in Route Monitoring messages. It MAY periodically send Stats Reports or even new Initiation messages, - according to configuration. If any new monitored BGP peers become - Established, corresponding Peer Up messages are sent. If any BGP + according to configuration. If any new monitored BGP peer becomes + Established, a corresponding Peer Up message is sent. If any BGP peers for which Peer Up messages were sent transition out of the Established state, corresponding Peer Down messages are sent. A BMP session ends when the TCP session that carries it is closed for any reason. The router MAY send a Termination message prior to closing the session. 4. BMP Message Format 4.1. Common Header @@ -307,74 +308,74 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer BGP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - o Peer Type (1 byte): These bits identify the type of the peer. - Currently only two types of peers are identified, + o Peer Type (1 byte): Identifies the type of the peer. Currently + two types of peers are identified, * Peer Type = 0: Global Instance Peer * Peer Type = 1: L3 VPN Instance Peer o Peer Flags (1 byte): These flags provide more information about the peer. The flags are defined as follows. 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |V|L|A| Reserved| +-+-+-+-+-+-+-+-+ * The V flag indicates the the Peer address is an IPv6 address. For IPv4 peers this is set to 0. - * The L flag, if set to 1, indicates that the message reflects - the post-policy Adj-RIB-In (i.e., its path attributes reflect - the application of inbound policy). It is set to 0 if the - message reflects the pre-policy Adj-RIB-In. Locally-sourced - routes also carry an L flag of 1. See Section 5 for further - detail. This flag has no significance when used with route - mirroring messages (Section 4.7). - * The A flag, if set to 1, indicates that the message is - formatted using the legacy two-byte AS_PATH format. If set to - 0, the message is formatted using the four-byte AS_PATH format + * The L flag, if set to 1, indicates the message reflects the + post-policy Adj-RIB-In (i.e., its path attributes reflect the + application of inbound policy). It is set to 0 if the message + reflects the pre-policy Adj-RIB-In. Locally-sourced routes + also carry an L flag of 1. See Section 5 for further detail. + This flag has no significance when used with route mirroring + messages (Section 4.7). + * The A flag, if set to 1, indicates the message is formatted + using the legacy two-byte AS_PATH format. If set to 0, the + message is formatted using the four-byte AS_PATH format [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH information as received from its peer, or it MAY choose to reformat all AS_PATH information into four-byte format regardless of how it was received from the peer. In the latter case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be sent in the BMP UPDATE message. This flag has no significance when used with route mirroring messages (Section 4.7). * The remaining bits are reserved for future use. o Peer Distinguisher (8 bytes): Routers today can have multiple instances (example L3VPNs). This field is present to distinguish peers that belong to one address domain from the other. If the peer is a "Global Instance Peer", this field is zero filled. If the peer is a "L3VPN Instance Peer", it is set to the - route distinguisher of the particular L3VPN instance that the peer + route distinguisher of the particular L3VPN instance the peer belongs to. o Peer Address: The remote IP address associated with the TCP session over which the encapsulated PDU was received. It is 4 - bytes long if an IPv4 address is carried in this field (with most - significant bytes zero filled) and 16 bytes long if an IPv6 - address is carried in this field. + bytes long if an IPv4 address is carried in this field (with the + 12 most significant bytes zero-filled) and 16 bytes long if an + IPv6 address is carried in this field. o Peer AS: The Autonomous System number of the peer from which the encapsulated PDU was received. If a 16 bit AS number is stored in - this field [RFC6793], it should be padded with zeroes in the most - significant bits. + this field [RFC6793], it should be padded with zeroes in the 16 + most significant bits. o Peer BGP ID: The BGP Identifier of the peer from which the encapsulated PDU was received. o Timestamp: The time when the encapsulated routes were received (one may also think of this as the time when they were installed in the Adj-RIB-In), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation- dependent. @@ -404,23 +405,23 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Information Type (2 bytes): Type of information provided. Defined types are: * Type = 0: String. The Information field contains a free-form UTF-8 string whose length is given by the "Information Length" - field. The value is administratively assigned. Note that - there is no requirement to terminate the string with a null (or - any other particular) character -- the length field gives its + field. The value is administratively assigned. There is no + requirement to terminate the string with a null (or any other + particular) character -- the length field gives its termination. If multiple strings are included, their ordering MUST be preserved when they are reported. * Type = 1: sysDescr. The Information field contains an ASCII string whose value MUST be set to be equal to the value of the sysDescr MIB-II [RFC1213] object. * Type = 2: sysName. The Information field contains a ASCII string whose value MUST be set to be equal to the value of the sysName MIB-II [RFC1213] object. @@ -469,53 +470,53 @@ + Reason = 0: Session administratively closed. The session might be re-initiated. + Reason = 1: Unspecified reason. + Reason = 2: Out of resources. The router has exhausted resources available for the BMP session. + Reason = 3: Redundant connection. The router has determined - that this connection is redundant with another one. + this connection is redundant with another one. + Reason = 4: Session permanently administratively closed, - will not be re-initiated. Collector should reduce + will not be re-initiated. Monitoring station should reduce (potentially to zero) the rate at which it attempts reconnection to the monitored router. o Information Length (2 bytes): The length of the following Information field, in bytes. o Information (variable): Information about the monitored router, according to the type. 4.6. Route Monitoring Route Monitoring messages are used for initial synchronization of - ADJ-RIBs-In. They are also used for ongoing monitoring of received - advertisements and withdraws. Route monitoring messages are state- - compressed. This is all discussed in more detail in Section 5. + ADJ-RIBs-In. They are also used for ongoing monitoring of ADJ-RIB-In + state. Route monitoring messages are state-compressed. This is all + discussed in more detail in Section 5. Following the common BMP header and per-peer header is a BGP Update PDU. 4.7. Route Mirroring Route Mirroring messages are used for verbatim duplication of messages as received. A possible use for mirroring is exact mirroring of one or more monitored BGP sessions, without state compression. Another possible use is mirroring of messages that have been treated-as-withdraw [I-D.ietf-idr-error-handling], for debugging - purposes. Mirrored messages may be sampled, or may provide complete - fidelity. The Messages Lost Information code is provided to allow - this to be communicated. Section 6 provides more detail. + purposes. Mirrored messages may be sampled, or may be lossless. The + Messages Lost Information code is provided to allow losses to be + indicated. Section 6 provides more detail. Following the common BMP header and per-peer header is a set of TLVs that contain information about a message or set of messages. Each TLV comprises a two-byte type code, a two-byte length field, and a variable-length value. Inclusion of any given TLV is OPTIONAL, however at least one TLV SHOULD be included, otherwise what's the point of sending the message? Defined TLVs are as follows: o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an Update message. If the BGP Message TLV occurs in the Route @@ -632,107 +633,108 @@ o Stat Type = 11: (32-bit Counter) Number of updates subjected to treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. o Stat Type = 13: (32-bit Counter) Number of duplicate update messages received. - Note that although the current specification only specifies 4-byte - counters and 8-byte gauges as "Stat Data", this does not preclude - future versions from incorporating more complex TLV-type "Stat Data" - (for example, one which can carry prefix specific data). SR messages - are optional. However if an SR message is transmitted, at least one - statistic MUST be carried in it. + Although the current specification only specifies 4-byte counters and + 8-byte gauges as "Stat Data", this does not preclude future versions + from incorporating more complex TLV-type "Stat Data" (for example, + one that can carry prefix specific data). SR messages are optional. + However if an SR message is transmitted, at least one statistic MUST + be carried in it. 4.9. Peer Down Notification - This message is used to indicate that a peering session was - terminated. + This message is used to indicate a peering session was terminated. 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (present if Reason = 1, 2 or 3) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reason indicates why the session was closed. Defined values are: o Reason 1: The local system closed the session. Following the Reason is a BGP PDU containing a BGP NOTIFICATION message that would have been sent to the peer. o Reason 2: The local system closed the session. No notification message was sent. Following the reason code is a two-byte field - containing the code corresponding to the FSM Event which caused - the system to close the session (see Section 8.1 of [RFC4271]). - Two bytes both set to zero are used to indicate that no relevant - Event code is defined. + containing the code corresponding to the FSM Event that caused the + system to close the session (see Section 8.1 of [RFC4271]). Two + bytes both set to zero are used to indicate no relevant Event code + is defined. o Reason 3: The remote system closed the session with a notification message. Following the Reason is a BGP PDU containing the BGP NOTIFICATION message as received from the peer. o Reason 4: The remote system closed the session without a - notification message. + notification message. This includes any unexpected termination of + the transport session, so in some cases both the local and remote + systems might consider this to apply. o Reason 5: Information for this peer will no longer be sent to the monitoring station for configuration reasons. This does not, - strictly speaking, indicate that the peer has gone down, but it - does indicate that the monitoring station will not receive updates - for the peer. + strictly speaking, indicate the peer has gone down, but it does + indicate the monitoring station will not receive updates for the + peer. A Peer Down message implicitly withdraws all routes that had been associated with the peer in question. A BMP implementation MAY omit sending explicit withdraws for such routes. 4.10. Peer Up Notification - The Peer Up message is used to indicate that a peering session has - come up (i.e., has transitioned into ESTABLISHED state). Following - the common BMP header and per-peer header is the following: + The Peer Up message is used to indicate a peering session has come up + (i.e., has transitioned into ESTABLISHED state). Following the + common BMP header and per-peer header is the following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Address (16 bytes) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sent OPEN Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received OPEN Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Local Address: The local IP address associated with the peering TCP session. It is 4 bytes long if an IPv4 address is carried in - this field, as determined by the V flag (with most significant - bytes zero filled) and 16 bytes long if an IPv6 address is carried - in this field. + this field, as determined by the V flag (with the 12 most + significant bytes zero-filled) and 16 bytes long if an IPv6 + address is carried in this field. o Local Port: The local port number associated with the peering TCP session, or zero if no TCP session actually exists (see Section 8.2). o Remote Port: The remote port number associated with the peering TCP session, or zero if no TCP session actually exists (see - Section 8.2). (Note that the remote address can be found in the - Peer Address field of the fixed header.) + Section 8.2). (The remote address can be found in the Peer + Address field of the fixed header.) o Sent OPEN Message: The full OPEN message transmitted by the monitored router to its peer. o Received OPEN Message: The full OPEN message received by the monitored router from its peer. o Information: Information about the peer, using the Information TLV (Section 4.4) format. Only the string type is defined in this context; it may be repeated. Inclusion of the Information field @@ -746,162 +748,167 @@ of each monitored peer. This is done by sending all routes stored in the Adj-RIB-In of those peers using standard BGP Update messages, encapsulated in Route Monitoring messages. There is no requirement on the ordering of messages in the peer dumps. When the initial dump is completed for a given peer, this MUST be indicated by sending an End-of-RIB marker for that peer (as specified in Section 2 of [RFC4724], plus the BMP encapsulation header). See also Section 9. A BMP speaker may send pre-policy routes, post-policy routes, or both. The selection may be due to implementation constraints (it is - possible that a BGP implementation may not store, for example, routes - which have been filtered out by policy). Pre-policy routes MUST have - their L flag clear in the BMP header (see Section 4), post-policy - routes MUST have their L flag set. When an implementation chooses to - send both pre- and post-policy routes, it is effectively multiplexing - two update streams onto the BMP session. The streams are - distinguished by their L flags. + possible a BGP implementation may not store, for example, routes that + have been filtered out by policy). Pre-policy routes MUST have their + L flag clear in the BMP header (see Section 4), post-policy routes + MUST have their L flag set. When an implementation chooses to send + both pre- and post-policy routes, it is effectively multiplexing two + update streams onto the BMP session. The streams are distinguished + by their L flags. If the implementation is able to provide information about when routes were received, it MAY provide such information in the BMP timestamp field. Otherwise, the BMP timestamp field MUST be set to - zero, indicating that time is not available. + zero, indicating time is not available. Ongoing monitoring is accomplished by propagating route changes in BGP Update PDUs and forwarding those PDUs to the monitoring station, again using RM messages. When a change occurs to a route, such as an - attribute change, the router must update the monitor with the new - attribute. As discussed above, it MAY generate either an update with - the L flag clear, with it set, or two updates, one with the L flag - clear and the other with the L flag set. When a route is withdrawn - by a peer, a corresponding withdraw is sent to the monitor. The - withdraw MUST have its L flag set to correspond to that of any - previous announcement; if the route in question was previously - announced with L flag both clear and set, the withdraw MUST similarly - be sent twice, with L flag clear and set. Multiple changed routes - MAY be grouped into a single BGP UPDATE PDU when feasible, exactly as - in the standard BGP protocol. + attribute change, the router must update the monitoring station with + the new attribute. As discussed above, it MAY generate either an + update with the L flag clear, with it set, or two updates, one with + the L flag clear and the other with the L flag set. When a route is + withdrawn by a peer, a corresponding withdraw is sent to the + monitoring station. The withdraw MUST have its L flag set to + correspond to that of any previous announcement; if the route in + question was previously announced with L flag both clear and set, the + withdraw MUST similarly be sent twice, with L flag clear and set. + Multiple changed routes MAY be grouped into a single BGP UPDATE PDU + when feasible, exactly as in the standard BGP protocol. - It's important to note that RM messages are not replicated messages - received from a peer. While the router should attempt to generate - updates as soon as they are received there is a finite time that - could elapse between reception of an update and the generation an RM - message and its transmission to the monitoring station. If there are - state changes in the interim for that prefix, it is acceptable that - the router generate the final state of that prefix to the monitoring - station. This is sometimes known as "state compression". The actual - PDU generated and transmitted to the station might also differ from - the exact PDU received from the peer, for example due to differences + It's important to note RM messages are not replicated messages + received from a peer. (Route mirroring (Section 6) is provided if + this is required.) While the router should attempt to generate + updates promptly there is a finite time that could elapse between + reception of an update, the generation an RM message, and its + transmission to the monitoring station. If there are state changes + in the interim for that prefix, it is acceptable that the router + generate the final state of that prefix to the monitoring station. + This is sometimes known as "state compression". The actual PDU + generated and transmitted to the station might also differ from the + exact PDU received from the peer, for example due to differences between how different implementations format path attributes. 6. Route Mirroring Route Mirroring messages are provided for two primary reasons: First, to enable an implementation to operate in a mode where it provides a full-fidelity view of all messages received from its peers, without state compression. As we note in Section 5, BMP's normal operational mode cannot provide this. Implementors are strongly cautioned that without state compression, an implementation could require unbounded storage to buffer messages queued to be mirrored. This requirement, - and concomitant performance implications, means that this mode of - operation is unlikely to be suitable for implementation in - conventional routers, and its use is NOT RECOMMENDED except in cases - where implementors have carefully considered the tradeoffs. + its concomitant performance implications, and other possible negative + consequences such as the potential to flow-block BGP peers, slowing + routing convergence, means this mode of operation is unlikely to be + suitable for implementation in conventional routers, and its use is + NOT RECOMMENDED except in cases where implementors have carefully + considered the tradeoffs. The second application for Route Mirroring is for error reporting and diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router can process BGP messages that are determined to contain errors, without resetting the BGP session. Such messages MAY be mirrored. The buffering used for such mirroring SHOULD be limited. If an errored message is unable to be mirrored due to buffer exhaustion, a message with the "Messages Lost" code SHOULD be sent to indicate - this. (This implies that a buffer should be reserved for this use.) + this. (This implies a buffer should be reserved for this use.) 7. Stat Reports As outlined above, SR messages are used to monitor specific events and counters on the monitored router. One type of monitoring could be to find out if there are an undue number of route advertisements and withdraws happening (churn) on the monitored router. Another metric is to evaluate the number of looped AS-Paths on the router. While this document proposes a small set of counters to begin with, the authors envision this list may grow in the future with new - applications that require BMP style monitoring. + applications that require BMP-style monitoring. 8. Other Considerations 8.1. Multiple Instances Some routers may support multiple instances of the BGP protocol, for example as "logical routers" or through some other facility. The BMP protocol relates to a single instance of BGP; thus, if a router supports multiple BGP instances it should also support multiple BMP instances (one per BGP instance). 8.2. Locally-Originated Routes - Some consideration is required for routes that are originated into - BGP by the local router, whether as a result of redistribution from a - another protocol or for some other reason. + Some consideration is required for routes originated into BGP by the + local router, whether as a result of redistribution from a another + protocol or for some other reason. Such routes can be modeled as having been sent by the router to itself, placing the router's own address in the Peer Address field of the header. It is RECOMMENDED that when doing so the router should use the same address it has used as its local address for the BMP session. Since in this case no transport session actually exists the Local and Remote Port fields of the Peer Up message MUST be set to zero. Clearly the OPEN Message fields of the Peer Up message will equally not have been physically transmitted, but should represent the relevant capabilities of the local router. - Also recall that the L flag is used to indicate locally-sourced - routes, see Section 4.2. + Also recall the L flag is used to indicate locally-sourced routes, + see Section 4.2. 9. Using BMP Once the BMP session is established route monitoring starts dumping the current snapshot as well as incremental changes simultaneously. It is fine to have these operations occur concurrently. If the initial dump visits a route and subsequently a withdraw is received, - this will be forwarded to the monitoring station which would have to + this will be forwarded to the monitoring station that would have to correlate and reflect the deletion of that route in its internal state. This is an operation a monitoring station would need to support regardless. If the router receives a withdraw for a prefix even before the peer dump procedure visits that prefix, then the router would clean up that route from its internal state and will not forward it to the monitoring station. In this case, the monitoring station may receive - a bogus withdraw which it can safely ignore. + a bogus withdraw it can safely ignore. 10. IANA Considerations - IANA is requested to create the following registries. + IANA is requested to create the registries for the following BMP + parameters. 10.1. BMP Message Types This document defines five message types for transferring BGP messages between cooperating systems (Section 4): o Type 0: Route Monitor o Type 1: Statistics Report o Type 2: Peer Down Notification o Type 3: Peer Up Notification o Type 4: Initiation o Type 5: Termination o Type 6: Mirroring Type values 7 through 128 MUST be assigned using the "Standards - Action" policy, and values 129 through 255 using the "Specification - Required" policy defined in [RFC5226]. + Action" policy, and values 129 through 250 using the "Specification + Required" policy defined in [RFC5226]. Values 251 through 254 are + "Experimental" and value 255 is reserved. 10.2. BMP Statistics Types This document defines nine statistics types for statistics reporting (Section 4.8): o Stat Type = 0: Number of prefixes rejected by inbound policy. o Stat Type = 1: Number of (known) duplicate prefix advertisements. o Stat Type = 2: Number of (known) duplicate withdraws. o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST @@ -912,103 +919,108 @@ in AS_CONFED_SEQUENCE or AS_CONFED_SET. o Stat Type = 7: Number of routes in Adj-RIBs-In. o Stat Type = 8: Number of routes in Loc-RIB. o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. o Stat Type = 11: Number of updates subjected to treat-as-withdraw. o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw. o Stat Type = 13: Number of duplicate update messages received. Stat Type values 14 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 10.3. BMP Initiation Message TLVs This document defines three types for information carried in the Initiation message (Section 4.3): o Type = 0: String. o Type = 1: sysDescr. o Type = 2: sysName. Information type values 3 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 10.4. BMP Termination Message TLVs This document defines two types for information carried in the Termination message (Section 4.5): o Type = 0: String. o Type = 1: Reason. Information type values 2 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 10.5. BMP Termination Message Reason Codes This document defines four types for information carried in the Termination message (Section 4.5) Reason code,: o Type = 0: Administratively closed. o Type = 1: Unspecified reason. o Type = 2: Out of resources. o Type = 3: Redundant connection. o Type = 4: Permanently administratively closed. Information type values 5 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 10.6. BMP Peer Down Reason Codes This document defines five types for information carried in the Peer Down Notification (Section 4.9) Reason code: o Type = 1: Local system closed, NOTIFICATION PDU follows. o Type = 2: Local system closed, FSM Event follows. o Type = 3: Remote system closed, NOTIFICATION PDU follows. o Type = 4: Remote system closed, no data. o Type = 5: Peer de-configured. Information type values 6 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. Value 0 is - reserved. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and values 0 and 65535 are reserved. 10.7. Route Mirroring TLVs This document defines two types for information carried in the Route Mirroring message (Section 4.7): o Type = 0: BGP Message. o Type = 1: Information. Information type values 2 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 10.8. BMP Route Mirroring Information Codes This document defines two types for information carried in the Route Mirroring Information (Section 4.7) code: o Type = 0: Errored PDU. o Type = 1: Messages Lost. Information type values 2 through 32767 MUST be assigned using the - "Standards Action" policy, and values 32768 through 65535 using the - "Specification Required" policy, defined in [RFC5226]. Value 0 is - reserved. + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are "Experimental" and value 65535 is reserved. 11. Security Considerations This document defines a mechanism to obtain a full dump or provide continuous monitoring of a BGP speaker's local BGP table, including received BGP messages. This capability could allow an outside party to obtain information not otherwise obtainable. Implementations of this protocol MUST require manual configuration of the monitored and monitoring devices. @@ -1107,21 +1120,22 @@ o Changed assignment policy for IANA registries. o Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In", plus other editorial changes. o Introduced option for monitoring station to be active party in initiating connection. o Introduced Termination message. o Added "route mirroring" mode. o Added "A" flag to identify AS Path format in use. Authors' Addresses - John Scudder + + John Scudder (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: jgs@juniper.net Rex Fernando Cisco Systems 170 W. Tasman Dr.