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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/