One document matched: draft-ietf-grow-bmp-17.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1213 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1213.xml">
<!ENTITY RFC1155 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1155.xml">
<!ENTITY RFC2856 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2856.xml">
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4303 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC5226 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC2629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4271 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC6793 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6793.xml">
<!ENTITY RFC4724 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4724.xml">
<!ENTITY RFC4364 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC7606 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-grow-bmp-17"
ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="BGP Monitoring Protocol">
BGP Monitoring Protocol</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="John Scudder" initials="J"
surname="Scudder" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>jgs@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rex Fernando" initials="R"
surname="Fernando">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>rex@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stephen Stuart" initials="S"
surname="Stuart">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<!-- Reorder these if your country does things differently -->
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>sstuart@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>IDR</keyword>
<keyword>BGP</keyword>
<keyword>GROW</keyword>
<keyword>BMP</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document defines a protocol, BMP, that can be used to monitor
BGP sessions. BMP is intended to provide a convenient interface for
obtaining route views. Prior to introduction of BMP, screen-scraping
was the most commonly-used approach to obtaining such views. The
design goals are to keep BMP simple, useful, easily implemented, and
minimally service-affecting. BMP is not suitable for use as a
routing protocol.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
Many researchers and network operators wish to have access to the
contents of routers' BGP RIBs as well as a view of protocol updates
the router is receiving. This monitoring task cannot be realized by
standard protocol mechanisms. Prior to introduction of BMP, this data
could only be obtained through screen-scraping.
</t>
<t>
The BMP protocol provides access to the Adj-RIB-In of a peer on an
ongoing basis and a periodic dump of certain statistics the
monitoring station can use for further analysis. From a high
level, BMP can be thought of as the result of multiplexing together
the messages received on the various monitored BGP sessions.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section> <!-- for Introductions section -->
<section title="Definitions">
<t>
<list style="symbols">
<t>
Adj-RIB-In: As defined in <xref target="RFC4271"></xref>, "The Adj-RIBs-In
contains unprocessed routing information that has been advertised to the
local BGP speaker by its peers." This is also referred to as the
pre-policy Adj-RIB-In in this document.
</t>
<t>
Post-Policy Adj-RIB-In: The result of applying inbound policy to an
Adj-RIB-In, but prior to the application of route selection to form
the Loc-RIB.
</t>
</list>
</t>
</section>
<section title="Overview of BMP Operation" anchor="overview">
<section title="BMP Messages">
<t>
The following
are the messages provided by BMP.
</t>
<t>
<list style="symbols">
<t>
Route Monitoring (RM): Used to provide an initial dump of all routes
received from a peer as well as an ongoing mechanism that
sends the incremental routes advertised and withdrawn by a peer
to the monitoring station.
</t>
<t>
Peer Down Notification: A message sent to indicate a
peering session has gone down with information indicating the
reason for the session disconnect.
</t>
<t>
Stats Reports (SR): An ongoing dump of statistics that
can be used by the monitoring station as a high level indication
of the activity going on in the router.
</t>
<t>
Peer Up Notification: A message sent to indicate a
peering session has come up. The message includes information
regarding the data exchanged between the peers in their OPEN
messages as well as information about the peering TCP session
itself. In addition to being sent whenever a peer transitions
to ESTABLISHED state, a Peer Up Notification is sent for
each peer in ESTABLISHED state when the BMP session
itself comes up.
</t>
<t>
Initiation: A means for the monitored router to inform
the monitoring station of its vendor, software version, and so on.
</t>
<t>
Termination: A means for the monitored router to inform the
monitoring station of why it is closing a BMP session.
</t>
<t>
Route Mirroring: a means for the monitored router to send verbatim
duplicates of messages as received. Can be used to exactly mirror a
monitored BGP session. Can also be used to report malformed BGP
PDUs.
</t>
</list>
</t>
</section>
<section title="Connection Establishment and Termination" anchor="connection">
<t>
BMP operates over TCP. All options are controlled by configuration
on the monitored router. No BMP message is ever sent from the monitoring
station to the monitored router. The monitored router MAY take steps
to prevent the monitoring station from sending data (for example by
half-closing the TCP session or setting its window size to zero) or
it MAY silently discard any data sent by the monitoring
station.
</t>
<t>
The router may be monitored by one or more monitoring stations.
With respect to each (router, monitoring station) pair, one party
is active with respect to TCP session establishment, and the other
party is passive. Which party is active and which is passive is
controlled by configuration.
</t>
<t>
The passive party is configured to listen on a particular
TCP port and the active party is configured to establish a
connection to that port. If the active party is unable to
connect to the passive party, it periodically retries the
connection. Retries MUST be subject to some variety of backoff.
Exponential backoff with a default initial backoff
of 30 seconds and a maximum of 720 seconds is suggested.
</t>
<t>
The router MAY restrict the set of IP addresses from which it will
accept connections. It SHOULD restrict the number of simultaneous
connections it will permit from a given IP address. The default value
for this restriction SHOULD be 1, though an implementation MAY permit
this restriction to be disabled in configuration. The router MUST
also restrict the rate at which sessions may be established. A
suggested default is an establishment rate of 2 sessions per minute.
</t>
<t>
A router (or management station) MAY implement logic to detect
redundant connections, as might occur if both parties are
configured to be active, and MAY elect to terminate redundant
connections. A Termination reason code is defined for this purpose.
</t>
<t>
Once a connection is established, the router sends messages over it.
There is no initialization or handshaking phase, messages are simply
sent as soon as the connection is established.
</t>
<t>
If the monitoring station intends to end or restart BMP processing, it
simply drops the connection.
</t>
</section>
<section title="Lifecycle of a BMP Session">
<t>
A router is configured to speak BMP to one or more monitoring stations.
It MAY be configured to send monitoring information for only a subset of
its BGP peers. Otherwise, all BGP peers are assumed to be monitored.
</t>
<t>
A BMP session begins when the active party (either router or
management station, as determined by configuration) successfully opens a TCP
session (the "BMP session"). Once the session is up, the router begins
to send BMP messages. It MUST begin by sending an Initiation message.
It subsequently
sends a Peer Up message over the BMP session for each of its monitored BGP peers
that is in Established state. It follows by sending the contents of
its Adj-RIBs-In (pre-policy, post-policy or both, see <xref
target="route_monitoring"></xref>) encapsulated in Route Monitoring
messages. Once it has sent all the routes for a given peer, it MUST send a
End-of-RIB message for that peer; when End-of-RIB has been sent for each monitored
peer, the initial table dump has completed. (A monitoring station that
wishes only to gather a table dump could close the connection once it
has gathered an End-of-RIB or Peer Down message corresponding to each
Peer Up message.)
</t>
<t>
Following the initial table dump, the router sends incremental updates
encapsulated in Route Monitoring messages. It MAY periodically send
Stats Reports or even new Initiation messages, according to
configuration. If any new monitored BGP peer becomes Established, a corresponding
Peer Up message is sent. If any BGP peers for which Peer Up messages
were sent transition out of the Established state, corresponding Peer
Down messages are sent.
</t>
<t>
A BMP session ends when the TCP session that carries it is closed for
any reason. The router MAY send a Termination message prior to closing
the session.
</t>
</section>
</section>
<section title="BMP Message Format" anchor="bmp_message_format">
<section title="Common Header" anchor="common_header">
<t>
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 common header.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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 |
+---------------+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Version (1 byte): Indicates the BMP version. This is set to '3'
for all messages defined in this specification. Version 0 is
reserved and MUST NOT be sent.
</t>
<t>
Message Length (4 bytes): Length of the message in bytes (including
headers, data and encapsulated messages, if any).
</t>
<t>
Message Type (1 byte): This identifies the type of the BMP
message. A BMP implementation MUST ignore unrecognized message types
upon receipt.
<list style="symbols">
<t>
Type = 0: Route Monitoring
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Statistics Report
</t>
<t>
Type = 2: Peer Down Notification
</t>
<t>
Type = 3: Peer Up Notification
</t>
<t>
Type = 4: Initiation Message
</t>
<t>
Type = 5: Termination Message
</t>
<t>
Type = 6: Route Mirroring Message
</t>
</list>
<?rfc subcompact="no" ?>
</t>
</list>
</t>
</section>
<section title="Per-Peer Header" anchor="per_peer_header">
<t>
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.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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 Distinguisher (present based on peer type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Peer Type (1 byte): Identifies the type of the
peer. Currently two types of peers are identified,
<list style="symbols">
<t>
Peer Type = 0: Global Instance Peer
</t>
<?rfc subcompact="yes" ?>
<t>
Peer Type = 1: RD Instance Peer
</t>
<t>
Peer Type = 2: Local Instance Peer
</t>
</list>
<?rfc subcompact="no" ?>
</t>
<t>
Peer Flags (1 byte): These flags provide more information about
the peer. The flags are defined as follows.
</t>
</list>
</t>
<t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|V|L|A| Reserved|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<?rfc subcompact="yes" ?>
<t>
<list style="empty">
<t>
<list style="symbols">
<t>
The V flag indicates the the Peer address is an IPv6 address.
For IPv4 peers this is set to 0.
</t>
<t>
The L flag, if set to 1, indicates the message reflects the
post-policy Adj-RIB-In (i.e., its path attributes reflect the
application of inbound policy). It is set to 0 if the message
reflects the pre-policy Adj-RIB-In. Locally-sourced routes also
carry an L flag of 1. See <xref
target="route_monitoring"></xref> for further detail. This flag
has no significance when used with <xref
target="route_mirroring_msg">route mirroring messages</xref>.
</t>
<t>
The A flag, if set to 1, indicates the message is formatted
using the legacy two-byte AS_PATH format. If set to 0, the
message is formatted using the four-byte AS_PATH format <xref
target="RFC6793"></xref>. A BMP speaker MAY choose to propagate
the AS_PATH information as received from its peer, or it MAY
choose to reformat all AS_PATH information into four-byte format
regardless of how it was received from the peer. In the latter
case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be
sent in the BMP UPDATE message. This flag has no significance
when used with <xref target="route_mirroring_msg">route
mirroring messages</xref>.
</t>
<t>
The remaining bits are reserved for future use. They MUST be
transmitted as zero and their values MUST be ignored on receipt.
</t>
</list>
<?rfc subcompact="no" ?>
</t>
</list>
</t>
<t>
<list style="symbols">
<t>
Peer Distinguisher (8 bytes): Routers today can have multiple
instances (example: <xref target="RFC4364">L3VPNs</xref>). This field is present to distinguish
peers that belong to one address domain from the other.
<vspace blankLines="1"/>
If the peer is a "Global Instance Peer", this field is zero
filled. If the peer is a "RD Instance Peer", it is set to the
route distinguisher of the particular instance the
peer belongs to. If the peer is a "Local Instance Peer", it
is set to a unique, locally-defined value. In all cases, the
effect is that the combination of the Peer Type and Peer Distinguisher
is sufficient to disambiguate peers for which other identifying
information might overlap.
</t>
<t>
Peer Address: The remote IP address associated with the TCP
session over which the encapsulated PDU was received. It is 4
bytes long if an IPv4 address is carried in this field (with the 12 most
significant bytes zero-filled) and 16 bytes long if an IPv6
address is carried in this field.
</t>
<t>
Peer AS: The Autonomous System number of the peer from which the
encapsulated PDU was received. If a 16 bit AS number is stored
in this field <xref target="RFC6793"></xref>, it should be padded
with zeroes in the 16 most significant bits.
</t>
<t>
Peer BGP ID: The BGP Identifier of the peer from which the
encapsulated PDU was received.
</t>
<t>
Timestamp: The time when the encapsulated routes were received
(one may also think of this as the time when they were installed in
the Adj-RIB-In),
expressed in seconds and microseconds since
midnight (zero hour), January 1, 1970 (UTC). If zero, the time is
unavailable. Precision of the timestamp is implementation-dependent.
</t>
</list>
</t>
</section>
<section title="Initiation Message" anchor="initiation">
<t>
The initiation message provides a means for the monitored router
to inform the monitoring station of its vendor, software version,
and so on. 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.
</t>
<t>
The initiation message consists of the common BMP header followed by
two or more <xref target="info_tlv">Information TLVs</xref>
containing information about the monitored router. The sysDescr and
sysName Information TLVs MUST be sent, any others are optional. The
string TLV MAY be included multiple times.
</t>
</section>
<section title="Information TLV" anchor="info_tlv">
<t>
The Information TLV is used by the <xref target="initiation">Initiation</xref>
and <xref target="peer_up_notification">Peer Up</xref> messages.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Information Type (2 bytes): Type of information provided.
Defined types are:
<list style="symbols">
<t>
Type = 0: String. The Information field contains a free-form
UTF-8 string whose length is given by the "Information Length"
field. The value is administratively assigned. There is
no requirement to terminate the string with a null (or any other
particular) character -- the length field gives its termination.
If multiple strings are included, their ordering MUST be preserved
when they are reported.
</t>
<t>
Type = 1: sysDescr. The Information field contains an ASCII
string whose value MUST be set to be equal to the value of
the sysDescr <xref target="RFC1213">MIB-II</xref> object.
</t>
<t>
Type = 2: sysName. The Information field contains a ASCII
string whose value MUST be set to be equal to the value of
the sysName <xref target="RFC1213">MIB-II</xref> object.
</t>
</list>
</t>
<t>
Information Length (2 bytes): The length of the following
Information field, in bytes.
</t>
<t>
Information (variable): Information about the monitored
router, according to the type.
</t>
</list>
</t>
</section>
<section title="Termination Message" anchor="termination">
<t>
The termination message provides a way for a monitored router to
indicate why it is terminating a session. Although use of this
message is RECOMMENDED, a monitoring station must always be
prepared for the session to terminate with no message. Once the
router has sent a termination message, it MUST close the TCP
session without sending any further messages. Likewise, the
monitoring station MUST close the TCP session after receiving
a termination message.
</t>
<t>
The termination message consists of the common BMP header followed
by one or more TLVs containing information about the reason for
the termination, as follows:
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Information Type (2 bytes): Type of information provided.
Defined types are:
<list style="symbols">
<t>
Type = 0: String. The Information field contains a free-form
UTF-8 string whose length is given by the "Information Length"
field. Inclusion of this TLV is optional. It MAY be used to
provide further detail for any of the defined reasons. Multiple
String TLVs MAY be included in the message.
</t>
<t>
Type = 1: Reason. The Information field contains a two-byte
code indicating the reason the connection was terminated.
Some reasons may have further TLVs associated with them.
Inclusion of this TLV is REQUIRED. Defined reasons are:
<list style="symbols">
<t>
Reason = 0: Session administratively closed. The session
might be re-initiated.
</t>
<t>
Reason = 1: Unspecified reason.
</t>
<t>
Reason = 2: Out of resources. The router has exhausted
resources available for the BMP session.
</t>
<t>
Reason = 3: Redundant connection. The router has
determined this connection is redundant with
another one.
</t>
<t>
Reason = 4: Session permanently administratively closed, will not be
re-initiated. Monitoring station should reduce (potentially to zero) the
rate at which it attempts reconnection to the monitored router.
</t>
</list>
</t>
</list>
</t>
<t>
Information Length (2 bytes): The length of the following
Information field, in bytes.
</t>
<t>
Information (variable): Information about the monitored
router, according to the type.
</t>
</list>
</t>
</section>
<section title="Route Monitoring" anchor="route_monitoring_msg">
<t>
Route Monitoring messages are used for initial synchronization of
ADJ-RIBs-In. They are also used for ongoing monitoring of ADJ-RIB-In
state. Route monitoring messages are
state-compressed. This is all discussed in more detail in
<xref target="route_monitoring"></xref>.
</t>
<t>
Following the common BMP header and per-peer header is a
BGP Update PDU.
</t>
</section>
<section title="Route Mirroring" anchor="route_mirroring_msg">
<t>
Route Mirroring messages are used for verbatim duplication of
messages as received. A possible use for mirroring is exact mirroring
of one or more monitored BGP sessions, without state compression.
Another possible use is mirroring of messages that have been
treated-as-withdraw <xref target="RFC7606"/>, for
debugging purposes. Mirrored messages may be sampled, or may be
lossless. The Messages Lost Information code is provided to
allow losses to be indicated. <xref target="route_mirroring">
</xref> provides more detail.
</t>
<t>
Following the common BMP header and per-peer header is a set
of TLVs that contain information about a message or set of
messages. Each TLV comprises a two-byte type code, a two-byte
length field, and a variable-length value. Inclusion of any
given TLV is OPTIONAL, however at least one TLV SHOULD be
included, otherwise what's the point of sending the message?
Defined TLVs are as follows:
</t>
<t>
<list style="symbols">
<t>
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
Mirroring message, it MUST occur last in the list of TLVs.
</t>
<t>
Type = 1: Information. A two-byte code that provides information
about the mirrored message or message stream. Defined codes are:
<list style="symbols">
<t>
Code = 0: Errored PDU. The contained message was found to have
some error that made it unusable, causing it to be
treated-as-withdraw <xref target="RFC7606"/>.
A BGP Message TLV MUST also occur in the TLV list.
</t>
<t>
Code = 1: Messages Lost. One or more messages may have been
lost. This could occur, for example, if an implementation runs
out of available buffer space to queue mirroring messages.
</t>
</list>
</t>
</list>
</t>
<t>
A Route Mirroring message may be sent any time it would be legal to
send a Route Monitoring message.
</t>
</section>
<section title="Stats Reports" anchor="stats_reports">
<t>
These messages contain information that could be used by the
monitoring station to observe interesting events that occur on the
router.
</t>
<t>
Transmission of SR messages could be timer triggered or
event driven (for example, when a significant event occurs or a
threshold is reached). This specification does not impose any
timing restrictions on when and on what event these reports have to
be transmitted. It is left to the implementation to determine
transmission timings -- however, configuration control should be
provided of the timer and/or threshold values. This document
only specifies the form and content of SR messages.
</t>
<t>
Following the common BMP header and per-peer header is a 4-byte field that indicates
the number of counters in the stats message where each counter is
encoded as a TLV.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Each counter is encoded as follows,
</t>
<figure align="center">
<artwork align="center"><![CDATA[
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 Data |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Stat Type (2 bytes): Defines the type of the statistic carried
in the "Stat Data" field.
</t>
<t>
Stat Len (2 bytes): Defines the length of the "Stat Data" Field.
</t>
</list>
</t>
<t>
This specification defines the following statistics. A BMP
implementation
MUST ignore unrecognized stat types on receipt, and likewise MUST
ignore unexpected data in the Stat Data field.
</t>
<t>
Stats are either counters or gauges, defined as follows after the
examples of <xref target="RFC1155"></xref> Section 3.2.3.3 and
<xref target="RFC2856"></xref> Section 4 respectively:
</t>
<t>
32-bit Counter: A non-negative integer which
monotonically increases until it reaches a maximum value, when it
wraps around and starts increasing again from zero. It has
a maximum value of 2^32-1 (4294967295 decimal).
</t>
<t>
64-bit Gauge: non-negative integer, which may increase or decrease,
but shall never exceed a maximum value, nor fall below a minimum
value. The maximum value can not be greater than 2^64-1
(18446744073709551615 decimal), and the minimum value can not be
smaller than 0. The value has its maximum value whenever the
information being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information being
modeled is smaller than or equal to its minimum value. If the
information being modeled subsequently decreases below (increases
above) the maximum (minimum) value, the 64-bit Gauge also
decreases (increases).
</t>
<t>
<list style="symbols">
<t>
Stat Type = 0: (32-bit Counter) Number of prefixes rejected by inbound policy.
</t>
<t>
Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix advertisements.
</t>
<t>
Stat Type = 2: (32-bit Counter) Number of (known) duplicate withdraws.
</t>
<t>
Stat Type = 3: (32-bit Counter) Number of updates invalidated due to CLUSTER_LIST loop.
</t>
<t>
Stat Type = 4: (32-bit Counter) Number of updates invalidated due to AS_PATH loop.
</t>
<t>
Stat Type = 5: (32-bit Counter) Number of updates invalidated due to ORIGINATOR_ID.
</t>
<t>
Stat Type = 6: (32-bit Counter) Number of updates invalidated due to AS_CONFED loop.
</t>
<t>
Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
</t>
<t>
Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
</t>
<t>
Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The value is
structured as: AFI (2 bytes), SAFI (1 byte), followed by a 64-bit Gauge.
</t>
<t>
Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is
structured as: AFI (2 bytes), SAFI (1 byte), followed by a 64-bit Gauge.
</t>
<t>
Stat Type = 11: (32-bit Counter) Number of updates subjected to treat-as-withdraw
treatment <xref target="RFC7606"/>.
</t>
<t>
Stat Type = 12: (32-bit Counter) Number of prefixes subjected to treat-as-withdraw
treatment <xref target="RFC7606"/>.
</t>
<t>
Stat Type = 13: (32-bit Counter) Number of duplicate update messages received.
</t>
</list>
</t>
<t>
Although the current specification only specifies 4-byte counters
and 8-byte gauges as "Stat
Data", this does not preclude future versions from incorporating more
complex TLV-type "Stat Data" (for example, one that can carry
prefix specific data). SR messages are optional. However if an SR
message is transmitted, at least one statistic
MUST be carried in it.
</t>
</section>
<section title="Peer Down Notification" anchor="peer_down_notification">
<t>
This message is used to indicate a peering session was
terminated.
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (present if Reason = 1, 2 or 3) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Reason indicates why the session was closed. Defined values are:
</t>
<t>
<list style="symbols">
<t>
Reason 1: The local system closed the session. Following the
Reason is a BGP PDU containing a BGP NOTIFICATION message that
would have been sent to the peer.
</t>
<t>
Reason 2: The local system closed the session. No notification
message was sent. Following the reason code is a two-byte
field containing the code corresponding to the FSM Event
that caused the system to close the session (see Section 8.1
of <xref target="RFC4271"></xref>). Two bytes both set to zero
are used to indicate
no relevant Event code is defined.
</t>
<t>
Reason 3: The remote system closed the session with a
notification message. Following the
Reason is a BGP PDU containing the BGP NOTIFICATION message
as received from the peer.
</t>
<t>
Reason 4: The remote system closed the session without a
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.
</t>
<t>
Reason 5: Information for this peer will no longer be sent
to the monitoring station for configuration reasons. This
does not, strictly speaking, indicate the peer has gone
down, but it does indicate the monitoring station will
not receive updates for the peer.
</t>
</list>
</t>
<t>
A Peer Down message implicitly withdraws all routes that had been
associated with the peer in question. A BMP implementation MAY
omit sending explicit withdraws for such routes.
</t>
</section>
<section title="Peer Up Notification" anchor="peer_up_notification">
<t>
The Peer Up message is used to indicate a peering session has
come up (i.e., has transitioned into ESTABLISHED state). Following
the common BMP header and per-peer header is the following:
</t>
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | Remote Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sent OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols">
<t>
Local Address: The local IP address associated with the peering TCP
session. It is 4 bytes long if an IPv4 address is carried in this
field, as determined by the V flag (with the 12 most significant bytes
zero-filled) and 16 bytes long if an IPv6 address is carried in
this field.
</t>
<t>
Local Port: The local port number associated with the peering TCP
session, or zero if no TCP session actually exists (see
<xref target="locally_originated_routes"/>).
</t>
<t>
Remote Port: The remote port number associated with the peering TCP
session, or zero if no TCP session actually exists (see <xref
target="locally_originated_routes"/>). (The remote
address can be found in the Peer Address field of the fixed header.)
</t>
<t>
Sent OPEN Message: The full OPEN message transmitted by the
monitored router to its peer.
</t>
<t>
Received OPEN Message: The full OPEN message received by the
monitored router from its peer.
</t>
<t>
Information: Information about the peer, using the
<xref target="info_tlv">Information TLV</xref> format. Only the
string type is defined in this context; it may be repeated.
Inclusion of the Information field is OPTIONAL. Its presence
or absence can be inferred by inspection of the Message Length
in the common header.
</t>
</list>
</t>
</section>
</section>
<section title="Route Monitoring" anchor="route_monitoring">
<t>
In BMP's normal operating mode, after the BMP session is up, Route Monitoring messages are used to
provide a snapshot of the Adj-RIB-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, encapsulated in Route Monitoring
messages. There is no requirement on the
ordering of messages in the peer dumps. When the initial dump
is completed for a given peer, this MUST be indicated by sending an End-of-RIB
marker for that peer (as specified in Section 2 of <xref target="RFC4724"></xref>,
plus the BMP encapsulation header). See also
<xref target="using_bmp"></xref>.
</t>
<t>
A BMP speaker may send pre-policy routes, post-policy routes, or
both. The selection may be due to implementation constraints (it
is possible a BGP implementation may not store, for example,
routes that have been filtered out by policy). Pre-policy routes
MUST have their L flag clear in the BMP header (see
<xref target="bmp_message_format"></xref>), post-policy routes
MUST have their L flag set. When an implementation chooses to send
both pre- and post-policy routes, it is effectively multiplexing
two update streams onto the BMP session. The streams are distinguished
by their L flags.
</t>
<t>
If the implementation is able to provide information about when
routes were received, it MAY provide such information in the BMP
timestamp field. Otherwise, the BMP timestamp field MUST be set to
zero, indicating time is not available.
</t>
<t>
Ongoing monitoring is accomplished by propagating route
changes in BGP Update PDUs and forwarding those PDUs to the
monitoring station, again using RM messages. When a change
occurs to a route, such as an attribute change, the router
must update the monitoring station with the new attribute. As discussed
above, it MAY generate either an update with the L flag clear,
with it set, or two updates, one with the L flag clear
and the other with the L flag set. When a route
is withdrawn by a peer, a corresponding withdraw is sent to
the monitoring station. The withdraw MUST have its L flag set to correspond
to that of any previous announcement; if the route in question
was previously announced with L flag both clear and set, the
withdraw MUST similarly be sent twice, with L flag clear and set.
Multiple changed routes MAY be grouped into a single BGP UPDATE
PDU when feasible, exactly as in the standard BGP protocol.
</t>
<t>
It's important to note RM messages are not replicated
messages received from a peer. (<xref target="route_mirroring">Route mirroring</xref>
is provided if this is required.) While the router should attempt to
generate updates promptly there is a finite
time that could elapse between reception of an update, the
generation an RM message, and its transmission
to the monitoring station. If there are state
changes in the interim for that prefix, it is acceptable that the
router generate the final state of that prefix to the monitoring
station. This is sometimes known as "state compression". The
actual PDU generated and transmitted to the station might also differ
from the exact PDU received from the peer, for example due to
differences between how different implementations format path attributes.
</t>
</section>
<section title="Route Mirroring" anchor="route_mirroring">
<t>
Route Mirroring messages are provided for two primary reasons:
First, to enable an implementation to operate in a mode where it
provides a full-fidelity view of all messages received from its
peers, without state compression. As we note in <xref target="route_monitoring"></xref>, BMP's
normal operational mode cannot provide this. Implementors are
strongly cautioned that without state compression, an implementation
could require unbounded storage to buffer messages queued to be
mirrored. Route Mirroring is unlikely to be suitable for implementation
in conventional routers, and its use is NOT RECOMMENDED except in cases
where implementors have carefully considered the tradeoffs. These
tradeoffs include: router resource exhaustion, the potential to
flow-block BGP peers, and the slowing of routing convergence.
</t>
<t>
The second application for Route Mirroring is for error reporting and
diagnosis. When <xref target="RFC7606"/> is in
use, a router can process BGP messages that are determined to
contain errors, without resetting the BGP session. Such messages MAY
be mirrored. The buffering used for such mirroring SHOULD be limited.
If an errored message is unable to be mirrored due to buffer
exhaustion, a message with the "Messages Lost" code SHOULD be sent to
indicate this. (This implies a buffer should be reserved for
this use.)
</t>
</section>
<section title="Stat Reports" anchor="stat_reports">
<t>
As outlined above, SR messages are used to monitor specific events
and counters on the monitored router. One type of monitoring could
be to find out if there are an undue number of route advertisements
and withdraws happening (churn) on the monitored router. Another
metric is to evaluate the number of looped AS-Paths on the router.
</t>
<t>
While this document proposes a small set of counters to begin with,
the authors envision this list may grow in the future with new
applications that require BMP-style monitoring.
</t>
</section>
<section title="Other Considerations" anchor="other_considerations">
<section title="Multiple Instances">
<t>
Some routers may support multiple instances of the BGP protocol,
for example as "logical routers" or through some other facility.
The BMP protocol relates to a single instance of BGP; thus, if
a router supports multiple BGP instances it should also support
multiple BMP instances (one per BGP instance). Different BMP
instances SHOULD generate Initiation Messages that are distinct
from one another, for example by using distinguishable sysNames
or by inclusion of instance-identifying information in a string
TLV.
</t>
</section>
<section title="Locally-Originated Routes" anchor="locally_originated_routes">
<t>
Some consideration is required for routes originated into
BGP by the local router, whether as a result of redistribution from
a another protocol or for some other reason.
</t>
<t>
Such routes can be modeled as having been sent by the router to itself,
placing the router's own address in the Peer Address field of the
header. It is RECOMMENDED that when doing so the router should use
the same address it has used as its local address for the BMP session.
Since in this case no transport session actually exists the Local and
Remote Port fields of the Peer Up message MUST be set to zero.
Clearly the OPEN Message fields of the Peer Up message will equally
not have been physically transmitted, but should represent the relevant
capabilities of the local router.
</t>
<t>
Also recall the L flag is used to indicate locally-sourced routes,
see <xref target="per_peer_header"/>.
</t>
</section>
</section>
<section title="Using BMP" anchor="using_bmp">
<t>
Once the BMP session is established route monitoring starts
dumping the current snapshot as well as incremental changes
simultaneously.
</t>
<t>
It is fine to have these operations occur concurrently. If the
initial dump visits a route and subsequently a withdraw is
received, this will be forwarded to the monitoring station that
would have to correlate and reflect the deletion of that route in
its internal state. This is an operation a monitoring station
would need to support regardless.
</t>
<t>
If the router receives a withdraw for a prefix even before the peer
dump procedure visits that prefix, then the router would clean up
that route from its internal state and will not forward it to the
monitoring station. In this case, the monitoring station may
receive a bogus withdraw it can safely ignore.
</t>
</section>
<section title="IANA Considerations" anchor="iana_considerations">
<t>
IANA is requested to create registries for the following BMP
parameters, to be organized in a new group "BGP Monitoring Protocol
(BMP) Parameters":
</t>
<section title="BMP Message Types">
<t>
This document defines seven message types for transferring BGP messages
between cooperating systems (<xref target="bmp_message_format"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type 0: Route Monitoring
</t>
<?rfc subcompact="yes" ?>
<t>
Type 1: Statistics Report
</t>
<t>
Type 2: Peer Down Notification
</t>
<t>
Type 3: Peer Up Notification
</t>
<t>
Type 4: Initiation
</t>
<t>
Type 5: Termination
</t>
<t>
Type 6: Route Mirroring
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Type values 0 through 128 MUST be assigned using the "Standards Action"
policy, and values 129 through 250 using the "Specification Required"
policy defined in <xref target="RFC5226"></xref>. Values 251 through
254 are "Experimental" and value 255 is reserved.
</t>
</section>
<section title="BMP Peer Types">
<t>
This document defines two types of peers for purposes of interpreting
the Peer Distinguisher field (<xref target="per_peer_header"></xref>):
</t>
<t>
<list style="symbols">
<t>
Peer Type = 0: Global Instance Peer.
</t>
<?rfc subcompact="yes" ?>
<t>
Peer Type = 1: RD Instance Peer.
</t>
<t>
Peer Type = 2: Local Instance Peer.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Peer Type values 0 through 127 MUST be assigned using the "Standards
Action" policy, and values 128 through 250 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values
251 through 254 are "Experimental" and value 255 is reserved.
</t>
</section>
<section title="BMP Peer Flags">
<t>
This document defines three bit flags in the Peer Flags field of the
Per-Peer Header (<xref target="per_peer_header"></xref>). The bits
are numbered from zero (the high-order, or leftmost, bit) to seven
(the low-order, or rightmost, bit):
</t>
<t>
<list style="symbols">
<t>
Flag 0: V flag.
</t>
<?rfc subcompact="yes" ?>
<t>
Flag 1: L flag.
</t>
<t>
Flag 2: A flag.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Flags 3 through 7 MUST be assigned using the "Standards
Action" policy.
</t>
</section>
<section title="BMP Statistics Types">
<t>
This document defines fourteen statistics types for statistics reporting
(<xref target="stats_reports"></xref>):
</t>
<t>
<list style="symbols">
<t>
Stat Type = 0: Number of prefixes rejected by inbound policy.
</t>
<?rfc subcompact="yes" ?>
<t>
Stat Type = 1: Number of (known) duplicate prefix advertisements.
</t>
<t>
Stat Type = 2: Number of (known) duplicate withdraws.
</t>
<t>
Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST loop.
</t>
<t>
Stat Type = 4: Number of updates invalidated due to AS_PATH loop.
</t>
<t>
Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
</t>
<t>
Stat Type = 6: Number of updates invalidated due to a loop found in
AS_CONFED_SEQUENCE or AS_CONFED_SET.
</t>
<t>
Stat Type = 7: Number of routes in Adj-RIBs-In.
</t>
<t>
Stat Type = 8: Number of routes in Loc-RIB.
</t>
<t>
Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.
</t>
<t>
Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB.
</t>
<t>
Stat Type = 11: Number of updates subjected to treat-as-withdraw.
</t>
<t>
Stat Type = 12: Number of prefixes subjected to treat-as-withdraw.
</t>
<t>
Stat Type = 13: Number of duplicate update messages received.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Stat Type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values
65531 through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
<section title="BMP Initiation Message TLVs">
<t>
This document defines three types for information carried in the Initiation
message (<xref target="initiation"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type = 0: String.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: sysDescr.
</t>
<t>
Type = 2: sysName.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
<section title="BMP Termination Message TLVs">
<t>
This document defines two types for information carried in the Termination
message (<xref target="termination"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type = 0: String.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Reason.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
<section title="BMP Termination Message Reason Codes">
<t>
This document defines five types for information carried in the Termination
message (<xref target="termination"></xref>) Reason code,:
</t>
<t>
<list style="symbols">
<t>
Type = 0: Administratively closed.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Unspecified reason.
</t>
<t>
Type = 2: Out of resources.
</t>
<t>
Type = 3: Redundant connection.
</t>
<t>
Type = 4: Permanently administratively closed.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
<section title="BMP Peer Down Reason Codes">
<t>
This document defines five types for information carried in the Peer
Down Notification (<xref target="peer_down_notification"></xref>) Reason code
(and reserves one further type):
</t>
<t>
<list style="symbols">
<t>
Type = 0 is reserved.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Local system closed, NOTIFICATION PDU follows.
</t>
<t>
Type = 2: Local system closed, FSM Event follows.
</t>
<t>
Type = 3: Remote system closed, NOTIFICATION PDU follows.
</t>
<t>
Type = 4: Remote system closed, no data.
</t>
<t>
Type = 5: Peer de-configured.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and values 0 and 65535 are reserved.
</t>
</section>
<section title="Route Mirroring TLVs">
<t>
This document defines two types for information carried in the Route Mirroring
message (<xref target="route_mirroring_msg"></xref>):
</t>
<t>
<list style="symbols">
<t>
Type = 0: BGP Message.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Information.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
<section title="BMP Route Mirroring Information Codes">
<t>
This document defines two types for information carried in the Route
Mirroring Information (<xref target="route_mirroring_msg"></xref>) code:
</t>
<t>
<list style="symbols">
<t>
Type = 0: Errored PDU.
</t>
<?rfc subcompact="yes" ?>
<t>
Type = 1: Messages Lost.
</t>
<?rfc subcompact="no" ?>
</list>
</t>
<t>
Information type values 0 through 32767 MUST be assigned using the "Standards
Action" policy, and values 32768 through 65530 using the "Specification
Required" policy, defined in <xref target="RFC5226"></xref>. Values 65531
through 65534 are "Experimental" and value 65535 is reserved.
</t>
</section>
</section>
<section title="Security Considerations" anchor="security_considerations">
<t>
This document defines a mechanism to obtain a full dump or provide
continuous monitoring of a BGP speaker's BGP routes, including
received BGP messages. This capability could allow an outside party
to obtain information not otherwise obtainable. For example,
although it's hard to consider the content of BGP routes in the
public Internet to be confidential, BGP is used in private contexts
as well, for example for <xref target="RFC4364">L3VPN</xref>. As another
example, a clever attacker might be able to infer the content of the
monitored router's import policy by comparing the pre-policy routes
exposed by BMP, to post-policy routes exported in BGP.
</t>
<t>
Implementations of this protocol SHOULD require manual configuration of
the monitored and monitoring devices.
</t>
<t>
Unless a transport that provides mutual authentication is used, an
attacker could masquerade as the monitored router and trick a
monitoring station into accepting false information, or could
masquerade as a monitoring station and gain unauthorized access to
BMP data. Unless a transport that provides confidentiality is used, a
passive or active attacker could gain access to or tamper with the BMP data in flight.
</t>
<t>
Where the security considerations outlined above are a concern, users
of this protocol should use <xref target="RFC4303">IPsec</xref> in
tunnel mode with preshared keys.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens,
Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack
McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch,
Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members of the
GROW working group for their comments.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!--?rfc include=
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC1213;
&RFC2119;
&RFC4271;
&RFC6793;
&RFC5226;
&RFC4724;
&RFC7606;
</references>
<references title="Informative References">
&RFC1155;
&RFC2856;
&RFC4303;
&RFC4364;
</references>
<section title="Changes Between BMP Versions 1 and 2">
<t><list style="symbols">
<t>
Added Peer Up Message
</t>
<?rfc subcompact="yes" ?>
<t>
Added L flag
</t>
<t>
Editorial changes
</t>
<?rfc subcompact="no" ?>
</list></t>
</section>
<section title="Changes Between BMP Versions 2 and 3">
<t><list style="symbols">
<t>
Added a 32-bit length field to the fixed header.
</t>
<?rfc subcompact="yes" ?>
<t>
Clarified error handling.
</t>
<t>
Added new stat types: 5 (number of updates invalidated due to
ORIGINATOR_ID), 6 (number of updates invalidated due to
AS_CONFED_SEQUENCE/AS_CONFED_SET), 7 (number of routes in
Adj-RIB-In), 8 (number of routes in Loc-RIB), 9 (number of routes
in Adj-RIB-In, per AFI/SAFI), 10 (numer of routes in Loc-RIB, per
AFI/SAFI), 11 (number of updates subjected to treat-as-withdraw
treatment), 12 (number of prefixes subjected to treat-as-withdraw
treatment), and 13 (number of duplicate update messages received).
</t>
<t>
Defined counters and gauges for use with stat types.
</t>
<t>
For peer down messages, the relevant FSM event is to be sent in
type 2 messages. Added type 5 to indicate peer is no longer monitored.
</t>
<t>
Added local address and local and remote ports to the peer
up message. Also optional descriptive string.
</t>
<t>
Require End-of-RIB marker after initial dump.
</t>
<t>
Added Initiation message with string content.
</t>
<t>
Permit multiplexing pre- and post-policy feeds onto a single BMP
session.
</t>
<t>
Changed assignment policy for IANA registries.
</t>
<t>
Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In",
plus other editorial changes.
</t>
<t>
Introduced option for monitoring station to be active party in
initiating connection.
</t>
<t>
Introduced Termination message.
</t>
<t>
Added "route mirroring" mode.
</t>
<t>
Added "A" flag to identify AS Path format in use.
</t>
<?rfc subcompact="no" ?>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 06:35:40 |