draft-ietf-grow-bmp-03.txt   draft-ietf-grow-bmp-04.txt 
Network Working Group J. Scudder Network Working Group J. Scudder
Internet-Draft R. Fernando Internet-Draft Juniper Networks
Intended status: Standards Track Juniper Networks Intended status: Standards Track R. Fernando
Expires: June 17, 2010 S. Stuart Expires: December 16, 2010 Cisco Systems
S. Stuart
Google Google
December 14, 2009 June 14, 2010
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-03 draft-ietf-grow-bmp-04
Abstract Abstract
This document proposes a simple protocol, BMP, which can be used to This document proposes a simple protocol, BMP, which can be used to
monitor BGP sessions. BMP is intended to provide a more convenient monitor BGP sessions. BMP is intended to provide a more convenient
interface for obtaining route views for research purpose than the interface for obtaining route views for research purpose than the
screen-scraping approach in common use today. The design goals are screen-scraping approach in common use today. The design goals are
to keep BMP simple, useful, easily implemented, and minimally to keep BMP simple, useful, easily implemented, and minimally
service-affecting. BMP is not suitable for use as a routing service-affecting. BMP is not suitable for use as a routing
protocol. protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 16, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6 2.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 5
2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 2.3. Initiation Message . . . . . . . . . . . . . . . . . . . . 7
2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8 2.4. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 8
3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 8
4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6. Peer Down Notification . . . . . . . . . . . . . . . . . . 9
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10 2.7. Peer Up Notification . . . . . . . . . . . . . . . . . . . 10
6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 15
Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 that the router is
receiving. This monitoring task cannot be realized by standard receiving. This monitoring task cannot be realized by standard
protocol mechanisms. At present, this data can only be obtained protocol mechanisms. At present, this data can only be obtained
through screen-scraping. 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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
reason for the session disconnect. reason for the session disconnect.
o Stats Reports (SR): This is an ongoing dump of statistics that can o Stats Reports (SR): This is an ongoing dump of statistics that can
be used by the monitoring station as a high level indication of be used by the monitoring station as a high level indication of
the activity going on in the router. the activity going on in the router.
o Peer Up Notification (PU): A message sent to indicate that a o Peer Up Notification (PU): A message sent to indicate that a
peering session has come up. The message includes information peering session has come up. The message includes information
regarding the data exchanged between the peers in their OPEN regarding the data exchanged between the peers in their OPEN
messages as well as information about the peering TCP session messages as well as information about the peering TCP session
itself. 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.
BMP operates over TCP. All options are controlled by configuration BMP operates over TCP. All options are controlled by configuration
on the monitored router. No message is ever sent from the monitoring on the monitored router. No message is ever sent from the monitoring
station to the monitored router. The monitored router MAY take steps station to the monitored router. The monitored router MAY take steps
to prevent the monitoring station from sending data (e.g. by half- to prevent the monitoring station from sending data (e.g. by half-
closing the TCP session or setting its window size to zero) or it MAY closing the TCP session or setting its window size to zero) or it MAY
silently discard any data erroneously sent by the monitoring station. silently discard any data erroneously sent by the monitoring station.
The monitoring station is configured to listen on a particular TCP The monitoring station is configured to listen on a particular TCP
port and the router is configured to establish an active connection port and the router is configured to establish an active connection
skipping to change at page 5, line 15 skipping to change at page 5, line 17
connection and resends the messages. connection and resends the messages.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. BMP Message Format 2. BMP Message Format
2.1. Common Header
The following common header appears in all BMP messages. The rest of The following common header appears in all BMP messages. The rest of
the data in a BMP message is dependent on the "Message Type" field in the data in a BMP message is dependent on the "Message Type" field in
the common header. the common header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Length | Msg. Type | | Version | Message Length | Msg. Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Version (1 byte): Indicates the BMP version. This is set to '3'
for all messages defined in this specification.
o Message Length (2 bytes): Length of the message in bytes
(including headers, data and encapsulated messages, if any).
o Message Type (1 byte): This identifies the type of the BMP
message. A BMP implementation MUST ignore unrecognized message
types upon receipt.
* Type = 0: Route Monitoring
* Type = 1: Statistics Report
* Type = 2: Peer Down Notification
* Type = 3: Peer Up Notification
* Type = 4: Initiation Message
2.2. Per-Peer Header
The per-peer header follows the common header for most BMP messages.
The rest of the data in a BMP message is dependent on the "Message
Type" field in the common header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags | | Peer Type | Peer Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Distinguisher (present based on peer type) | | Peer Distinguisher (present based on peer type) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) | | Peer Address (16 bytes) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | | Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) | | Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) | | Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Version (1 byte): Indicates the BMP version. This is set to '3'
for all messages defined in this specification.
o Message Length (2 bytes): Length of the message in bytes
(including headers, data and encapsulated messages, if any).
o Message Type (1 byte): This identifies the type of the BMP
message. A BMP implementation MUST ignore unrecognized message
types upon receipt.
* Type = 0: Route Monitoring
* Type = 1: Statistics Report
* Type = 2: Peer Down Notification
* Type = 3: Peer Up Notification
o Peer Type (1 byte): These bits identify the type of the peer. o Peer Type (1 byte): These bits identify the type of the peer.
Currently only two types of peers are identified, Currently only 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| Reserved | |V|L| 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 that the message reflects
the Loc-RIB (i.e., it reflects the application of inbound the Loc-RIB (i.e., it reflects the application of inbound
policy). It is set to 0 if the message reflects the policy). It is set to 0 if the message reflects the
Adj-RIB-In. Adj-RIB-In. See Section 3 for further detail.
* 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 that the peer
belongs to. belongs to.
skipping to change at page 7, line 15 skipping to change at page 7, line 29
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.
2.1. Route Monitoring 2.3. Initiation Message
The initiation message provides a means for the monitored router to
inform the monitoring station of its vendor, software version, and so
on. The initiation message is OPTIONAL. When used, an initiation
message MUST be sent as the first message after the TCP session comes
up. An initiation message MAY be sent at any point thereafter, if
warranted by a change on the monitored router.
The initiation message consists of the common BMP header followed by
one or more TLVs containing information about the monitored router,
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Type | Information Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Information Type (2 bytes): Type of information provided. Defined
types are:
* Type = 0: String. The Information field contains a free-form
ASCII string whose length is given by the "Information Length"
field.
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.
2.4. Route Monitoring
Route Monitoring messages are used for initial synchronization of Route Monitoring messages are used for initial synchronization of
ADJ-RIB-In. They are also used for ongoing monitoring of received ADJ-RIB-In. They are also used for ongoing monitoring of received
advertisements and withdraws. This is discussed in more detail in advertisements and withdraws. This is discussed in more detail in
subsequent sections. subsequent sections.
Following the common BMP header is a BGP PDU. Following the common BMP header and per-peer header is a BGP PDU.
2.2. Stats Reports 2.5. Stats Reports
These messages contain information that could be used by the These messages contain information that could be used by the
monitoring station to observe interesting events that occur on the monitoring station to observe interesting events that occur on the
router. 'Stats Report' messages have a message type of '3'. router. 'Stats Report' messages have a message type of '3'.
The transmission of the SR messages could be timer triggered or event The transmission of the SR messages could be timer triggered or event
driven (for example, when a significant event occurs or a threshold driven (for example, when a significant event occurs or a threshold
is reached). This specification does not impose any timing is reached). This specification does not impose any timing
restrictions on when and on what event these reports have to be restrictions on when and on what event these reports have to be
transmitted. It is left to the implementation to determine transmitted. It is left to the implementation to determine
transmission timings -- however, configuration control should be transmission timings -- however, configuration control should be
provided of the timer and/or threshold values. This document only provided of the timer and/or threshold values. This document only
specifies the form and content of SR messages. specifies the form and content of SR messages.
Following the common BMP header is a 4-byte field that indicates the Following the common BMP header and per-peer header is a 4-byte field
number of counters in the stats message where each counter is encoded that indicates the number of counters in the stats message where each
as a TLV. counter is encoded as a TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stats Count | | Stats Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each counter is encoded as follows, Each counter is encoded as follows,
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Type | Stat Len | | Stat Type | Stat Len |
skipping to change at page 8, line 45 skipping to change at page 9, line 45
o Stat Type = 6: Number of updates invalidated due to AS_CONFED o Stat Type = 6: Number of updates invalidated due to AS_CONFED
loop. loop.
Note that the current specification only specifies 4-byte counters as Note that the current specification only specifies 4-byte counters as
"Stat Data". This does not preclude future versions from "Stat Data". This does not preclude future versions from
incorporating more complex TLV-type "Stat Data" (for example, one incorporating more complex TLV-type "Stat Data" (for example, one
which can carry prefix specific data). SR messages are optional. which can carry prefix specific data). SR messages are optional.
However if an SR message is transmitted, this specification requires However if an SR message is transmitted, this specification requires
at least one statistic to be carried in it. at least one statistic to be carried in it.
2.3. Peer Down Notification 2.6. Peer Down Notification
This message is used to indicate that a peering session was This message is used to indicate that a peering session was
terminated. The type of this message is 4. terminated. The type of this message is 4.
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) |
~ ~ ~ ~
skipping to change at page 9, line 32 skipping to change at page 10, line 32
the system to close the session (see Section 8.1 of [RFC4271]). the system to close the session (see Section 8.1 of [RFC4271]).
Zero is used to indicate that no relevant Event code is defined. Zero is used to indicate that no relevant Event code 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.
2.4. Peer Up Notification 2.7. Peer Up Notification
The Peer Up message is used to indicate that a peering session has The Peer Up message is used to indicate that a peering session has
come up (i.e., has transitioned into ESTABLISHED state). Following come up (i.e., has transitioned into ESTABLISHED state). Following
the common BMP header is the 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 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 |
~ ~ ~ ~
skipping to change at page 10, line 27 skipping to change at page 11, line 27
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.
3. Route Monitoring 3. Route Monitoring
After the BMP session is up, Route Monitoring messages are used to After the BMP session is up, Route Monitoring messages are used to
provide a snapshot of the Adj-RIB-In of a particular peer. It does provide a snapshot of the Adj-RIB-In of a particular peer. This is
so by sending all routes stored in the Adj-RIB-In of that peer using done by sending all routes stored in the Adj-RIB-In of that peer
standard BGP Update messages. There is no requirement on the using standard BGP Update messages. There is no requirement on the
ordering of messages in the peer dump. ordering of messages in the peer dump. When the initial peer dump is
completed, this MUST be indicated by sending an End-of-RIB marker (as
specified in Section 2 of [RFC4724], plus the BMP encapsulation
header).
Depending on the implementation or configuration, it may only be Depending on the implementation or configuration, it may only be
possible to send the Loc-RIB (post-policy routes) instead of the Adj- possible to send the Loc-RIB (post-policy routes) instead of the Adj-
RIB-In. This is because it is possible that a BGP implementation may RIB-In. This is because it is possible that a BGP implementation may
not store, for example, routes which have been filtered out by not store, for example, routes which have been filtered out by
policy. If this is the case, the implementation may send the Loc-RIB policy. If this is the case, the implementation may send the Loc-RIB
path that pertains to a particular peer in the route monitor message. path that pertains to a particular peer in the route monitor message.
Such paths MUST have the L flag set in the BMP header (see
Section 2).
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 that time is not available.
AS Numbers in the BMP UPDATE message MUST be sent as 4-octet
quantities, as described in [RFC4893]. This affects the AS_PATH and
AGGREGATOR path attributes. AS4_PATH or AS4_AGGREGATOR path
attributes MUST NOT be sent in a BMP UPDATE message, as it makes no
sense to do so.
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 monitor with the new
attribute. When a route is withdrawn by a peer, a corresponding attribute. When a route is withdrawn by a peer, a corresponding
withdraw is sent to the monitor. Multiple changed routes MAY be withdraw is sent to the monitor. Multiple changed routes MAY be
grouped into a single BGP UPDATE PDU when feasible, exactly as in the grouped into a single BGP UPDATE PDU when feasible, exactly as in the
standard BGP protocol. standard BGP protocol.
It's important to note that RM messages are not real time replicated It's important to note that RM messages are not real time replicated
skipping to change at page 12, line 11 skipping to change at page 13, line 25
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 which it can safely ignore.
7. IANA Considerations 7. IANA Considerations
This document defines four message types for transferring BGP This document defines five message types for transferring BGP
messages between cooperating systems (Section 2): messages between cooperating systems (Section 2):
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
Type values 4 through 255 MUST be assigned using the "IETF Consensus" Type values 5 through 128 MUST be assigned using the "Standards
policy defined in [RFC5226]. Action" policy, and values 129 through 255 using the "Specification
Required" policy defined in [RFC5226].
This document defines five statistics types for statistics reporting This document defines five statistics types for statistics reporting
(Section 2.2): (Section 2.5):
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
loop. loop.
o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. o Stat Type = 4: Number of updates invalidated due to AS_PATH loop.
o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
o Stat Type = 6: Number of updates invalidated due to AS_CONFED o Stat Type = 6: Number of updates invalidated due to AS_CONFED
loop. loop.
Stat Type values 7 through 32767 MUST be assigned using the "IETF Stat Type values 7 through 32767 MUST be assigned using the
Consensus" policy, and values 32768 through 65535 using the "First "Standards Action" policy, and values 32768 through 65535 using the
Come First Served" policy, defined in [RFC5226]. "Specification Required" policy, defined in [RFC5226].
This document defines one type for information carried in the
Initiation message (Section 2.3):
o Type = 0: String.
Information type values 1 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65535 using the
"Specification Required" policy, defined in [RFC5226].
8. Security Considerations 8. 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.
Users of this protocol MAY use some type of secure transmission Users of this protocol MAY use some type of secure transmission
mechanism, such as IPSec [RFC4303], to transmit this data. mechanism, such as IPSec [RFC4303], to transmit this data.
9. References 9. Acknowledgements
9.1. Normative References Thanks to John ji Ioannidis, Mack McBride, Danny McPherson, Dimitri
Papadimitriou, Erik Romijn, and the members of the GROW working group
for their comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative References 10.2. Informative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
Appendix A. Changes Between BMP Versions 1 and 2 Appendix A. Changes Between BMP Versions 1 and 2
o Added Peer Up Message o Added Peer Up Message
o Added L flag o Added L flag
o Editorial changes o Editorial changes
Appendix B. Changes Between BMP Versions 2 and 3 Appendix B. Changes Between BMP Versions 2 and 3
o Added a 16-bit length field to the fixed header. o Added a 16-bit length field to the fixed header.
o Clarified error handling. o Clarified error handling.
o Added stat types 5 and 6 (number of updates invalidated due to o Added stat types 5 and 6 (number of updates invalidated due to
ORIGINATOR_ID and AS_CONFED, respectively). ORIGINATOR_ID and AS_CONFED, respectively).
o For peer down messages, the relevant FSM event is to be sent in o For peer down messages, the relevant FSM event is to be sent in
type 2 messages. type 2 messages.
o Added local address and local and remote ports to the peer up o Added local address and local and remote ports to the peer up
message. message.
o Require End-of-RIB marker after initial dump.
o Added Initiation message with string content.
o Changed assignment policy for IANA registries.
o Editorial changes.
Authors' Addresses Authors' Addresses
John Scudder John Scudder
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
skipping to change at page 14, line 14 skipping to change at page 16, line 4
Authors' Addresses Authors' Addresses
John Scudder John Scudder
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
Juniper Networks Cisco Systems
1194 N. Mathilda Ave 170 W. Tasman Dr.
Sunnyvale, CA 94089 San Jose, CA 95134
USA USA
Email: rex@juniper.net Email: rex@cisco.com
Stephen Stuart Stephen Stuart
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: sstuart@google.com Email: sstuart@google.com
 End of changes. 37 change blocks. 
82 lines changed or deleted 164 lines changed or added

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