draft-ietf-grow-bmp-15.txt   draft-ietf-grow-bmp-16.txt 
Network Working Group J. Scudder, Ed. Network Working Group J. Scudder, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Fernando Intended status: Standards Track R. Fernando
Expires: February 12, 2016 Cisco Systems Expires: May 15, 2016 Cisco Systems
S. Stuart S. Stuart
Google Google
August 11, 2015 November 12, 2015
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-15 draft-ietf-grow-bmp-16
Abstract Abstract
This document defines a protocol, BMP, that can be used to monitor This document defines a protocol, BMP, that can be used to monitor
BGP sessions. BMP is intended to provide a convenient interface for BGP sessions. BMP is intended to provide a convenient interface for
obtaining route views. Prior to introduction of BMP, screen-scraping obtaining route views. Prior to introduction of BMP, screen-scraping
was the most commonly-used approach to obtaining such views. The was the most commonly-used approach to obtaining such views. The
design goals are to keep BMP simple, useful, easily implemented, and design goals are to keep BMP simple, useful, easily implemented, and
minimally service-affecting. BMP is not suitable for use as a minimally service-affecting. BMP is not suitable for use as a
routing protocol. routing protocol.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2016. This Internet-Draft will expire on May 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15
5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17
6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18
7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18
8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19
8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19
9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20
10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 10.2. BMP Peer Types . . . . . . . . . . . . . . . . . . . . . 20
10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 10.3. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 20
10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 10.4. BMP Statistics Types . . . . . . . . . . . . . . . . . . 21
10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 10.5. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21
10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 10.6. BMP Termination Message TLVs . . . . . . . . . . . . . . 22
10.7. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 22 10.7. BMP Termination Message Reason Codes . . . . . . . . . . 22
10.8. BMP Route Mirroring Information Codes . . . . . . . . . 22 10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22
10.9. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 23
10.10. BMP Route Mirroring Information Codes . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25
Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many researchers and network operators wish to have access to the Many researchers and network operators wish to have access to the
contents of routers' BGP RIBs as well as a view of protocol updates contents of routers' BGP RIBs as well as a view of protocol updates
the router is receiving. This monitoring task cannot be realized by the router is receiving. This monitoring task cannot be realized by
standard protocol mechanisms. Prior to introduction of BMP, this standard protocol mechanisms. Prior to introduction of BMP, this
skipping to change at page 4, line 46 skipping to change at page 4, line 46
monitoring station of why it is closing a BMP session. monitoring station of why it is closing a BMP session.
o Route Mirroring: a means for the monitored router to send verbatim o Route Mirroring: a means for the monitored router to send verbatim
duplicates of messages as received. Can be used to exactly mirror duplicates of messages as received. Can be used to exactly mirror
a monitored BGP session. Can also be used to report malformed BGP a monitored BGP session. Can also be used to report malformed BGP
PDUs. PDUs.
3.2. Connection Establishment and Termination 3.2. Connection Establishment and Termination
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 BMP message is ever sent from the
station to the monitored router. The monitored router MAY take steps monitoring station to the monitored router. The monitored router MAY
to prevent the monitoring station from sending data (for example by take steps to prevent the monitoring station from sending data (for
half-closing the TCP session or setting its window size to zero) or example by half-closing the TCP session or setting its window size to
it MAY silently discard any data sent by the monitoring station. zero) or it MAY silently discard any data sent by the monitoring
station.
The router may be monitored by one or more monitoring stations. With The router may be monitored by one or more monitoring stations. With
respect to each (router, monitoring station) pair, one party is respect to each (router, monitoring station) pair, one party is
active with respect to TCP session establishment, and the other party active with respect to TCP session establishment, and the other party
is passive. Which party is active and which is passive is controlled is passive. Which party is active and which is passive is controlled
by configuration. by configuration.
The passive party is configured to listen on a particular TCP port The passive party is configured to listen on a particular TCP port
and the active party is configured to establish a connection to that 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, port. If the active party is unable to connect to the passive party,
skipping to change at page 5, line 36 skipping to change at page 5, line 36
A router (or management station) MAY implement logic to detect A router (or management station) MAY implement logic to detect
redundant connections, as might occur if both parties are configured redundant connections, as might occur if both parties are configured
to be active, and MAY elect to terminate redundant connections. A to be active, and MAY elect to terminate redundant connections. A
Termination reason code is defined for this purpose. Termination reason code is defined for this purpose.
Once a connection is established, the router sends messages over it. Once a connection is established, the router sends messages over it.
There is no initialization or handshaking phase, messages are simply There is no initialization or handshaking phase, messages are simply
sent as soon as the connection is established. sent as soon as the connection is established.
If the monitoring station intends to end or restart BMP processing, If the monitoring station intends to end or restart BMP processing,
it simply drops the connection, optionally with a Termination it simply drops the connection.
message.
3.3. Lifecycle of a BMP Session 3.3. Lifecycle of a BMP Session
A router is configured to speak BMP to one or more monitoring A router is configured to speak BMP to one or more monitoring
stations. It MAY be configured to send monitoring information for stations. It MAY be configured to send monitoring information for
only a subset of its BGP peers. Otherwise, all BGP peers are assumed only a subset of its BGP peers. Otherwise, all BGP peers are assumed
to be monitored. to be monitored.
A BMP session begins when the active party (either router or A BMP session begins when the active party (either router or
management station, as determined by configuration) successfully management station, as determined by configuration) successfully
skipping to change at page 7, line 42 skipping to change at page 7, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) | | Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) | | Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Peer Type (1 byte): Identifies the type of the peer. Currently o Peer Type (1 byte): Identifies the type of the peer. Currently
two types of peers are identified, two types of peers are identified,
* Peer Type = 0: Global Instance Peer * Peer Type = 0: Global Instance Peer
* Peer Type = 1: L3 VPN Instance Peer * Peer Type = 1: RD Instance Peer
* Peer Type = 2: Local Instance Peer
o Peer Flags (1 byte): These flags provide more information about o Peer Flags (1 byte): These flags provide more information about
the peer. The flags are defined as follows. the peer. The flags are defined as follows.
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L|A| Reserved| |V|L|A| Reserved|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
* The V flag indicates the the Peer address is an IPv6 address. * The V flag indicates the the Peer address is an IPv6 address.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
* The A flag, if set to 1, indicates the message is formatted * 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 using the legacy two-byte AS_PATH format. If set to 0, the
message is formatted using the four-byte AS_PATH format message is formatted using the four-byte AS_PATH format
[RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH
information as received from its peer, or it MAY choose to information as received from its peer, or it MAY choose to
reformat all AS_PATH information into four-byte format reformat all AS_PATH information into four-byte format
regardless of how it was received from the peer. In the latter regardless of how it was received from the peer. In the latter
case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be
sent in the BMP UPDATE message. This flag has no significance sent in the BMP UPDATE message. This flag has no significance
when used with route mirroring messages (Section 4.7). when used with route mirroring messages (Section 4.7).
* The remaining bits are reserved for future use. * The remaining bits are reserved for future use. They MUST be
transmitted as zero and their values MUST be ignored on
receipt.
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 [RFC4364]). This field is present to
peers that belong to one address domain from the other. distinguish 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 "RD Instance Peer", it is set to the
route distinguisher of the particular L3VPN instance the peer route distinguisher of the particular instance the peer belongs
belongs to. 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.
o Peer Address: The remote IP address associated with the TCP o Peer Address: The remote IP address associated with the TCP
session over which the encapsulated PDU was received. It is 4 session over which the encapsulated PDU was received. It is 4
bytes long if an IPv4 address is carried in this field (with the 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 12 most significant bytes zero-filled) and 16 bytes long if an
IPv6 address is carried in this field. IPv6 address is carried in this field.
o Peer AS: The Autonomous System number of the peer from which the o Peer AS: The Autonomous System number of the peer from which the
encapsulated PDU was received. If a 16 bit AS number is stored in encapsulated PDU was received. If a 16 bit AS number is stored in
this field [RFC6793], it should be padded with zeroes in the 16 this field [RFC6793], it should be padded with zeroes in the 16
skipping to change at page 11, line 38 skipping to change at page 11, line 45
Following the common BMP header and per-peer header is a BGP Update Following the common BMP header and per-peer header is a BGP Update
PDU. PDU.
4.7. Route Mirroring 4.7. Route Mirroring
Route Mirroring messages are used for verbatim duplication of Route Mirroring messages are used for verbatim duplication of
messages as received. A possible use for mirroring is exact messages as received. A possible use for mirroring is exact
mirroring of one or more monitored BGP sessions, without state mirroring of one or more monitored BGP sessions, without state
compression. Another possible use is mirroring of messages that have compression. Another possible use is mirroring of messages that have
been treated-as-withdraw [I-D.ietf-idr-error-handling], for debugging been treated-as-withdraw [RFC7606], for debugging purposes. Mirrored
purposes. Mirrored messages may be sampled, or may be lossless. The messages may be sampled, or may be lossless. The Messages Lost
Messages Lost Information code is provided to allow losses to be Information code is provided to allow losses to be indicated.
indicated. Section 6 provides more detail. Section 6 provides more detail.
Following the common BMP header and per-peer header is a set of TLVs Following the common BMP header and per-peer header is a set of TLVs
that contain information about a message or set of messages. Each that contain information about a message or set of messages. Each
TLV comprises a two-byte type code, a two-byte length field, and a TLV comprises a two-byte type code, a two-byte length field, and a
variable-length value. Inclusion of any given TLV is OPTIONAL, variable-length value. Inclusion of any given TLV is OPTIONAL,
however at least one TLV SHOULD be included, otherwise what's the however at least one TLV SHOULD be included, otherwise what's the
point of sending the message? Defined TLVs are as follows: point of sending the message? Defined TLVs are as follows:
o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an
Update message. If the BGP Message TLV occurs in the Route Update message. If the BGP Message TLV occurs in the Route
Mirroring message, it MUST occur last in the list of TLVs. Mirroring message, it MUST occur last in the list of TLVs.
o Type = 1: Information. A two-byte code that provides information o Type = 1: Information. A two-byte code that provides information
about the mirrored message or message stream. Defined codes are: about the mirrored message or message stream. Defined codes are:
* Code = 0: Errored PDU. The contained message was found to have * Code = 0: Errored PDU. The contained message was found to have
some error that made it unusable, causing it to be treated-as- some error that made it unusable, causing it to be treated-as-
withdraw [I-D.ietf-idr-error-handling]. A BGP Message TLV MUST withdraw [RFC7606]. A BGP Message TLV MUST also occur in the
also occur in the TLV list. TLV list.
* Code = 1: Messages Lost. One or more messages may have been * Code = 1: Messages Lost. One or more messages may have been
lost. This could occur, for example, if an implementation runs lost. This could occur, for example, if an implementation runs
out of available buffer space to queue mirroring messages. out of available buffer space to queue mirroring messages.
A Route Mirroring message may be sent any time it would be legal to
send a Route Monitoring message.
4.8. Stats Reports 4.8. 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. router.
Transmission of SR messages could be timer triggered or event driven Transmission of SR messages could be timer triggered or event driven
(for example, when a significant event occurs or a threshold is (for example, when a significant event occurs or a threshold is
reached). This specification does not impose any timing restrictions reached). This specification does not impose any timing restrictions
on when and on what event these reports have to be transmitted. It on when and on what event these reports have to be transmitted. It
skipping to change at page 14, line 21 skipping to change at page 14, line 33
o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The o 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 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by
a 64-bit Gauge. a 64-bit Gauge.
o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The o 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 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by
a 64-bit Gauge. a 64-bit Gauge.
o Stat Type = 11: (32-bit Counter) Number of updates subjected to o Stat Type = 11: (32-bit Counter) Number of updates subjected to
treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. treat-as-withdraw treatment [RFC7606].
o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to
treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. treat-as-withdraw treatment [RFC7606].
o Stat Type = 13: (32-bit Counter) Number of duplicate update o Stat Type = 13: (32-bit Counter) Number of duplicate update
messages received. messages received.
Although the current specification only specifies 4-byte counters and Although the current specification only specifies 4-byte counters and
8-byte gauges as "Stat Data", this does not preclude future versions 8-byte gauges as "Stat Data", this does not preclude future versions
from incorporating more complex TLV-type "Stat Data" (for example, from incorporating more complex TLV-type "Stat Data" (for example,
one that can carry prefix specific data). SR messages are optional. one that can carry prefix specific data). SR messages are optional.
However if an SR message is transmitted, at least one statistic MUST However if an SR message is transmitted, at least one statistic MUST
be carried in it. be carried in it.
skipping to change at page 18, line 27 skipping to change at page 18, line 27
mode cannot provide this. Implementors are strongly cautioned that mode cannot provide this. Implementors are strongly cautioned that
without state compression, an implementation could require unbounded without state compression, an implementation could require unbounded
storage to buffer messages queued to be mirrored. Route Mirroring is storage to buffer messages queued to be mirrored. Route Mirroring is
unlikely to be suitable for implementation in conventional routers, unlikely to be suitable for implementation in conventional routers,
and its use is NOT RECOMMENDED except in cases where implementors and its use is NOT RECOMMENDED except in cases where implementors
have carefully considered the tradeoffs. These tradeoffs include: have carefully considered the tradeoffs. These tradeoffs include:
router resource exhaustion, the potential to flow-block BGP peers, router resource exhaustion, the potential to flow-block BGP peers,
and the slowing of routing convergence. and the slowing of routing convergence.
The second application for Route Mirroring is for error reporting and The second application for Route Mirroring is for error reporting and
diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router diagnosis. When [RFC7606] is in use, a router can process BGP
can process BGP messages that are determined to contain errors, messages that are determined to contain errors, without resetting the
without resetting the BGP session. Such messages MAY be mirrored. BGP session. Such messages MAY be mirrored. The buffering used for
The buffering used for such mirroring SHOULD be limited. If an such mirroring SHOULD be limited. If an errored message is unable to
errored message is unable to be mirrored due to buffer exhaustion, a be mirrored due to buffer exhaustion, a message with the "Messages
message with the "Messages Lost" code SHOULD be sent to indicate Lost" code SHOULD be sent to indicate this. (This implies a buffer
this. (This implies a buffer should be reserved for this use.) should be reserved for this use.)
7. Stat Reports 7. Stat Reports
As outlined above, SR messages are used to monitor specific events As outlined above, SR messages are used to monitor specific events
and counters on the monitored router. One type of monitoring could and counters on the monitored router. One type of monitoring could
be to find out if there are an undue number of route advertisements be to find out if there are an undue number of route advertisements
and withdraws happening (churn) on the monitored router. Another and withdraws happening (churn) on the monitored router. Another
metric is to evaluate the number of looped AS-Paths on the router. metric is to evaluate the number of looped AS-Paths on the router.
While this document proposes a small set of counters to begin with, While this document proposes a small set of counters to begin with,
skipping to change at page 20, line 29 skipping to change at page 20, line 29
o Type 3: Peer Up Notification o Type 3: Peer Up Notification
o Type 4: Initiation o Type 4: Initiation
o Type 5: Termination o Type 5: Termination
o Type 6: Route Mirroring o Type 6: Route Mirroring
Type values 0 through 128 MUST be assigned using the "Standards Type values 0 through 128 MUST be assigned using the "Standards
Action" policy, and values 129 through 250 using the "Specification Action" policy, and values 129 through 250 using the "Specification
Required" policy defined in [RFC5226]. Values 251 through 254 are Required" policy defined in [RFC5226]. Values 251 through 254 are
"Experimental" and value 255 is reserved. "Experimental" and value 255 is reserved.
10.2. BMP Statistics Types 10.2. BMP Peer Types
This document defines two types of peers for purposes of interpreting
the Peer Distinguisher field (Section 4.2):
o Peer Type = 0: Global Instance Peer.
o Peer Type = 1: RD Instance Peer.
o Peer Type = 2: Local Instance Peer.
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 [RFC5226]. Values 251 through 254 are
"Experimental" and value 255 is reserved.
10.3. BMP Peer Flags
This document defines three bit flags in the Peer Flags field of the
Per-Peer Header (Section 4.2). The bits are numbered from zero (the
high-order, or leftmost, bit) to seven (the low-order, or rightmost,
bit):
o Flag 0: V flag.
o Flag 1: L flag.
o Flag 2: A flag.
Flags 3 through 7 MUST be assigned using the "Standards Action"
policy.
10.4. BMP Statistics Types
This document defines fourteen statistics types for statistics This document defines fourteen statistics types for statistics
reporting (Section 4.8): reporting (Section 4.8):
o Stat Type = 0: Number of prefixes rejected by inbound policy. o Stat Type = 0: Number of prefixes rejected by inbound policy.
o Stat Type = 1: Number of (known) duplicate prefix advertisements. o Stat Type = 1: Number of (known) duplicate prefix advertisements.
o Stat Type = 2: Number of (known) duplicate withdraws. o Stat Type = 2: Number of (known) duplicate withdraws.
o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST
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.
skipping to change at page 21, line 7 skipping to change at page 21, line 35
o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB.
o Stat Type = 11: Number of updates subjected to treat-as-withdraw. o Stat Type = 11: Number of updates subjected to treat-as-withdraw.
o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw. o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw.
o Stat Type = 13: Number of duplicate update messages received. o Stat Type = 13: Number of duplicate update messages received.
Stat Type values 0 through 32767 MUST be assigned using the Stat Type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
10.3. BMP Initiation Message TLVs 10.5. BMP Initiation Message TLVs
This document defines three types for information carried in the This document defines three types for information carried in the
Initiation message (Section 4.3): Initiation message (Section 4.3):
o Type = 0: String. o Type = 0: String.
o Type = 1: sysDescr. o Type = 1: sysDescr.
o Type = 2: sysName. o Type = 2: sysName.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
10.4. BMP Termination Message TLVs 10.6. BMP Termination Message TLVs
This document defines two types for information carried in the This document defines two types for information carried in the
Termination message (Section 4.5): Termination message (Section 4.5):
o Type = 0: String. o Type = 0: String.
o Type = 1: Reason. o Type = 1: Reason.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
10.5. BMP Termination Message Reason Codes 10.7. BMP Termination Message Reason Codes
This document defines five types for information carried in the This document defines five types for information carried in the
Termination message (Section 4.5) Reason code,: Termination message (Section 4.5) Reason code,:
o Type = 0: Administratively closed. o Type = 0: Administratively closed.
o Type = 1: Unspecified reason. o Type = 1: Unspecified reason.
o Type = 2: Out of resources. o Type = 2: Out of resources.
o Type = 3: Redundant connection. o Type = 3: Redundant connection.
o Type = 4: Permanently administratively closed. o Type = 4: Permanently administratively closed.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
10.6. BMP Peer Down Reason Codes 10.8. BMP Peer Down Reason Codes
This document defines five types for information carried in the Peer This document defines five types for information carried in the Peer
Down Notification (Section 4.9) Reason code (and reserves one further Down Notification (Section 4.9) Reason code (and reserves one further
type): type):
o Type = 0 is reserved. o Type = 0 is reserved.
o Type = 1: Local system closed, NOTIFICATION PDU follows. o Type = 1: Local system closed, NOTIFICATION PDU follows.
o Type = 2: Local system closed, FSM Event follows. o Type = 2: Local system closed, FSM Event follows.
o Type = 3: Remote system closed, NOTIFICATION PDU follows. o Type = 3: Remote system closed, NOTIFICATION PDU follows.
o Type = 4: Remote system closed, no data. o Type = 4: Remote system closed, no data.
o Type = 5: Peer de-configured. o Type = 5: Peer de-configured.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and values 0 and 65535 are reserved. through 65534 are "Experimental" and values 0 and 65535 are reserved.
10.7. Route Mirroring TLVs 10.9. Route Mirroring TLVs
This document defines two types for information carried in the Route This document defines two types for information carried in the Route
Mirroring message (Section 4.7): Mirroring message (Section 4.7):
o Type = 0: BGP Message. o Type = 0: BGP Message.
o Type = 1: Information. o Type = 1: Information.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
10.8. BMP Route Mirroring Information Codes 10.10. BMP Route Mirroring Information Codes
This document defines two types for information carried in the Route This document defines two types for information carried in the Route
Mirroring Information (Section 4.7) code: Mirroring Information (Section 4.7) code:
o Type = 0: Errored PDU. o Type = 0: Errored PDU.
o Type = 1: Messages Lost. o Type = 1: Messages Lost.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
skipping to change at page 23, line 26 skipping to change at page 23, line 52
BMP, to post-policy routes exported in BGP. BMP, to post-policy routes exported in BGP.
Implementations of this protocol SHOULD require manual configuration Implementations of this protocol SHOULD require manual configuration
of the monitored and monitoring devices. of the monitored and monitoring devices.
Unless a transport that provides mutual authentication is used, an Unless a transport that provides mutual authentication is used, an
attacker could masquerade as the monitored router and trick a attacker could masquerade as the monitored router and trick a
monitoring station into accepting false information, or could monitoring station into accepting false information, or could
masquerade as a monitoring station and gain unauthorized access to masquerade as a monitoring station and gain unauthorized access to
BMP data. Unless a transport that provides confidentiality is used, BMP data. Unless a transport that provides confidentiality is used,
a passive attacker could gain access to BMP data in flight. However, a passive or active attacker could gain access to or tamper with the
BGP is not commonly deployed over a transport providing BMP data in flight. However, BGP is not commonly deployed over a
confidentiality, so it's debatable whether it's crucial to provide transport providing confidentiality, so it's debatable whether it's
confidentiality once the data is propagated into BMP. crucial to provide confidentiality once the data is propagated into
BMP.
Where the security considerations outlined above are a concern, users This document does not specify any security mechanism for BMP.
of this protocol should consider using some type of transport that
provides mutual authentication, data integrity and transport
protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If
confidentiality is considered a concern, a transport providing that
as well could be selected.
12. Acknowledgements 12. Acknowledgements
Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens,
Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack
McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom
Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members
of the GROW working group for their comments. of the GROW working group for their comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-error-handling]
Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages", draft-
ietf-idr-error-handling-19 (work in progress), April 2015.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
<http://www.rfc-editor.org/info/rfc1213>. <http://www.rfc-editor.org/info/rfc1213>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 24, line 40 skipping to change at page 25, line 5
[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,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>. <http://www.rfc-editor.org/info/rfc6793>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.
13.2. Informative References 13.2. Informative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets", of management information for TCP/IP-based internets",
STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990,
<http://www.rfc-editor.org/info/rfc1155>. <http://www.rfc-editor.org/info/rfc1155>.
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual
Conventions for Additional High Capacity Data Types", Conventions for Additional High Capacity Data Types",
RFC 2856, DOI 10.17487/RFC2856, June 2000, RFC 2856, DOI 10.17487/RFC2856, June 2000,
<http://www.rfc-editor.org/info/rfc2856>. <http://www.rfc-editor.org/info/rfc2856>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
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 32-bit length field to the fixed header. o Added a 32-bit length field to the fixed header.
o Clarified error handling. o Clarified error handling.
 End of changes. 31 change blocks. 
74 lines changed or deleted 103 lines changed or added

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