draft-ietf-grow-bmp-01.txt   draft-ietf-grow-bmp-02.txt 
Network Working Group J. Scudder Network Working Group J. Scudder
Internet-Draft R. Fernando Internet-Draft R. Fernando
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: October 10, 2009 S. Stuart Expires: January 14, 2010 S. Stuart
Google Google
April 8, 2009 July 13, 2009
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-01 draft-ietf-grow-bmp-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 24
monitor BGP sessions. BMP is intended to provide a more convenient monitor BGP sessions. BMP is intended to provide a more convenient
interface for obtaining route views for research purpose than the interface for obtaining route views for research purpose than the
screen-scraping approach in common use today. The design goals are screen-scraping approach in common use today. The design goals are
to keep BMP simple, useful, easily implemented, and minimally to keep BMP simple, useful, easily implemented, and minimally
service-affecting. BMP is not suitable for use as a routing service-affecting. BMP is not suitable for use as a routing
protocol. protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 5 2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6
2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7
2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8
3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8
4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Many researchers wish to have access to the contents of routers' BGP Many researchers wish to have access to the contents of routers' BGP
RIBs as well as a view of protocol updates that the router is RIBs as well as a view of protocol updates that the router is
receiving. This monitoring task cannot be realized by standard receiving. This monitoring task cannot be realized by standard
protocol mechanisms. At present, this data can only be obtained protocol mechanisms. At present, this data can only be obtained
through screen-scraping. through screen-scraping.
The BMP protocol provides access to the Adj-RIB-In of a peer on an The BMP protocol provides access to the Adj-RIB-In of a peer on an
skipping to change at page 3, line 31 skipping to change at page 3, line 31
station. station.
o Peer Down Notification (PD): A message sent to indicate that a o Peer Down Notification (PD): A message sent to indicate that a
peering session has gone down with information indicating the peering session has gone down with information indicating the
reason for the session disconnect. reason for the session disconnect.
o Stats Reports (SR): This is an ongoing dump of statistics that can o Stats Reports (SR): This is an ongoing dump of statistics that can
be used by the monitoring station as a high level indication of be used by the monitoring station as a high level indication of
the activity going on in the router. the activity going on in the router.
o Peer Up Notification (PU): A message sent to indicate that a
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.
BMP operates over TCP. All options are controlled by configuration BMP operates over TCP. All options are controlled by configuration
on the monitored router. Communication is unidirectional, from the on the monitored router. No message is ever sent from the monitoring
monitored router to the monitoring station. station to the monitored router. The monitored router MAY take steps
to prevent the monitoring station from sending data (e.g. by half-
closing the TCP session or setting its window size to zero) or it MAY
silently discard any data erroneously sent by the monitoring station.
The monitoring station is configured to listen on a particular TCP The monitoring station is configured to listen on a particular TCP
port and the router is configured to establish an active connection port and the router is configured to establish an active connection
to that port and to send messages on that TCP connection. There is to that port and to send messages on that TCP connection. There is
no initialization or handshaking phase, messages are simply sent as no initialization or handshaking phase, messages are simply sent as
soon as the connection is established. soon as the connection is established. If the router is unable to
connect to the monitoring station, it periodically retries the
connection. A suggested default retry period is 30 seconds.
If the monitoring station intends to restart BMP processing, it If the monitoring station intends to restart BMP processing, it
simply drops the connection. The router then re-establishes the simply drops the connection. The router then re-establishes the
connection and resends the messages. connection and resends the messages.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 4, line 30 skipping to change at page 4, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | | Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) | | Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) | | Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Version (1 byte): Indicates the BMP version. This is set to '1' o Version (1 byte): Indicates the BMP version. This is set to '2'
for all messages defined in this specification. for all messages defined in this specification.
o Message Type (1 byte): This identifies the type of the BMP o Message Type (1 byte): This identifies the type of the BMP
message, message,
* Type = 0: Route Monitoring * Type = 0: Route Monitoring
* Type = 1: Statistics Report * Type = 1: Statistics Report
* Type = 2: Peer Down Notification * Type = 2: Peer Down Notification
* Type = 3: Peer Up Notification
o Peer Type (1 byte): These bits identify the type of the peer. o Peer Type (1 byte): These bits identify the type of the peer.
Currently only two types of peers are identified, Currently only two types of peers are identified,
* Peer Type = 0: Global Instance Peer * Peer Type = 0: Global Instance Peer
* Peer Type = 1: L3 VPN Instance Peer * Peer Type = 1: L3 VPN Instance Peer
o Peer Flags (1 byte): These flags provide more information about o Peer Flags (1 byte): These flags provide more information about
the peer. The flags are defined as follows. the peer. The flags are defined as follows.
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V| Reserved | |V|L| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
* The V flag indicates the the Peer address is an IPv6 address. * The V flag indicates the the Peer address is an IPv6 address.
For IPv4 peers this is set to 0. For IPv4 peers this is set to 0.
* The L flag, if set to 1, indicates that the message reflects
the Loc-RIB (i.e., it reflects the application of inbound
policy). It is set to 0 if the message reflects the
Adj-RIB-In.
* The remaining bits are reserved for future use. * The remaining bits are reserved for future use.
o Peer Distinguisher (8 bytes): Routers today can have multiple o Peer Distinguisher (8 bytes): Routers today can have multiple
instances (example L3VPNs). This field is present to distinguish instances (example L3VPNs). This field is present to distinguish
peers that belong to one address domain from the other. peers that belong to one address domain from the other.
If the peer is a "Global Instance Peer", this field is zero If the peer is a "Global Instance Peer", this field is zero
filled. If the peer is a "L3VPN Instance Peer", it is set to the filled. If the peer is a "L3VPN Instance Peer", it is set to the
route distinguisher of the particular L3VPN instance that the peer route distinguisher of the particular L3VPN instance that the peer
belongs to. belongs to.
skipping to change at page 5, line 33 skipping to change at page 5, line 46
address is carried in this field. 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 [RFC4893], it should be padded with zeroes in the most this field [RFC4893], it should be padded with zeroes in the most
significant bits. significant bits.
o Peer BGP ID: The BGP Identifier of the peer from which the o Peer BGP ID: The BGP Identifier of the peer from which the
encapsulated PDU was received. encapsulated PDU was received.
o Timestamp: The time when the encapsulated PDU was received, o Timestamp: The time when the encapsulated routes were received
expressed in seconds and microseconds since midnight (zero hour), (one may also think of this as the time when they were installed
January 1, 1970 (UTC). If zero, the time is unavailable. 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.
2.1. Route Monitoring 2.1. Route Monitoring
Route Monitoring messages are used for initial synchronization of Route Monitoring messages are used for initial synchronization of
ADJ-RIB-In. They are also used for ongoing monitoring of received ADJ-RIB-In. They are also used for ongoing monitoring of received
advertisements and withdraws. This is discussed in more detail in advertisements and withdraws. This is discussed in more detail in
subsequent sections. subsequent sections.
Following the common BMP header is a BGP PDU. The length of the PDU Following the common BMP header is a BGP PDU. The length of the PDU
can be determined by parsing it in the normal fashion as specified in can be determined by parsing it in the normal fashion as specified in
skipping to change at page 6, line 16 skipping to change at page 6, line 29
These messages contain information that could be used by the These messages contain information that could be used by the
monitoring station to observe interesting events that occur on the monitoring station to observe interesting events that occur on the
router. 'Stats Report' messages have a message type of '3'. router. 'Stats Report' messages have a message type of '3'.
The transmission of the SR messages could be timer triggered or event The transmission of the SR messages could be timer triggered or event
driven (for example, when a significant event occurs or a threshold driven (for example, when a significant event occurs or a threshold
is reached). This specification does not impose any timing is reached). This specification does not impose any timing
restrictions on when and on what event these reports have to be restrictions on when and on what event these reports have to be
transmitted. It is left to the implementation to determine transmitted. It is left to the implementation to determine
transmission timings. This document only specifies the form and transmission timings -- however, configuration control should be
content of SR messages. provided of the timer and/or threshold values. This document only
specifies the form and content of SR messages.
Following the common BMP header is a 4-byte field that indicates the Following the common BMP header is a 4-byte field that indicates the
number of counters in the stats message where each counter is encoded number of counters in the stats message where each counter is encoded
as a TLV. as a TLV.
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stats Count | | Stats Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 5 skipping to change at page 8, line 17
o Reason 3: The remote system closed the session with a notification o Reason 3: The remote system closed the session with a notification
message. Following the Reason is a BGP PDU containing the BGP message. Following the Reason is a BGP PDU containing the BGP
NOTIFICATION message as received from the peer. The length of the NOTIFICATION message as received from the peer. The length of the
PDU can be determined by parsing it in the normal fashion as PDU can be determined by parsing it in the normal fashion as
specified in [RFC4271]. specified in [RFC4271].
o Reason 4: The remote system closed the session without a o Reason 4: The remote system closed the session without a
notification message. notification message.
2.4. Peer Up Notification
The Peer Up message is used to indicate that a peering session has
come up (i.e., has transitioned into ESTABLISHED state). Following
the common BMP header are the full OPEN messages as sent and received
by the BGP speaker. The OPEN message transmitted by the monitored
router to its peer is first, followed by the OPEN message received by
the monitored router from its peer.
The length of the full PU message is the length of the fixed header
plus the lengths of the two encapsulated OPEN messages which can be
determined by parsing them in the normal fashion as specified in
[RFC4271].
3. Route Monitoring 3. Route Monitoring
After the BMP session is up, Route Monitoring messages are used to After the BMP session is up, Route Monitoring messages are used to
provide a snapshot of the Adj-RIB-In of a particular peer. It does provide a snapshot of the Adj-RIB-In of a particular peer. It does
so by sending all routes stored in the Adj-RIB-In of that peer using so by sending all routes stored in the Adj-RIB-In of that peer using
standard BGP Update messages. There is no requirement on the standard BGP Update messages. There is no requirement on the
ordering of messages in the peer dump. ordering of messages in the peer dump.
Depending on the implementation or configuration, it may only be Depending on the implementation or configuration, it may only be
possible to send the Loc-RIB (post-policy routes) instead of the Adj- possible to send the Loc-RIB (post-policy routes) instead of the Adj-
skipping to change at page 9, line 10 skipping to change at page 9, line 36
As outlined above, SR messages are used to monitor specific events As outlined above, SR messages are used to monitor specific events
and counters on the monitored router. One type of monitoring could and counters on the monitored router. One type of monitoring could
be to find out if there are an undue number of route advertisements be to find out if there are an undue number of route advertisements
and withdraws happening (churn) on the monitored router. Another and withdraws happening (churn) on the monitored router. Another
metric is to evaluate the number of looped AS-Paths on the router. metric is to evaluate the number of looped AS-Paths on the router.
While this document proposes a small set of counters to begin with, While this document proposes a small set of counters to begin with,
the authors envision this list may grow in the future with new the authors envision this list may grow in the future with new
applications that require BMP style monitoring. applications that require BMP style monitoring.
5. Using BMP 5. Other Considerations
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 BMP instance).
6. Using BMP
Once the BMP session is established route monitoring starts dumping Once the BMP session is established route monitoring starts dumping
the current snapshot as well as incremental changes simultaneously. the current snapshot as well as incremental changes simultaneously.
It is fine to have these operations occur concurrently. If the It is fine to have these operations occur concurrently. If the
initial dump visits a route and subsequently a withdraw is received, initial dump visits a route and subsequently a withdraw is received,
this will be forwarded to the monitoring station which would have to this will be forwarded to the monitoring station which would have to
correlate and reflect the deletion of that route in its internal correlate and reflect the deletion of that route in its internal
state. This is an operation a monitoring station would need to state. This is an operation a monitoring station would need to
support regardless. support regardless.
If the router receives a withdraw for a prefix even before the peer If the router receives a withdraw for a prefix even before the peer
dump procedure visits that prefix, then the router would clean up dump procedure visits that prefix, then the router would clean up
that route from its internal state and will not forward it to the that route from its internal state and will not forward it to the
monitoring station. In this case, the monitoring station may receive monitoring station. In this case, the monitoring station may receive
a bogus withdraw which it can safely ignore. a bogus withdraw which it can safely ignore.
6. IANA Considerations 7. IANA Considerations
This document defines three message types for transferring BGP This document defines four message types for transferring BGP
messages between cooperating systems (Section 2): messages between cooperating systems (Section 2):
o Type 0: Route Monitor o Type 0: Route Monitor
o Type 1: Statistics Report o Type 1: Statistics Report
o Type 2: Peer Down Notification o Type 2: Peer Down Notification
o Type 3: Peer Up Notification
Type values 3 through 255 MUST be assigned using the "IETF Consensus" Type values 4 through 255 MUST be assigned using the "IETF Consensus"
policy defined in [RFC5226]. policy defined in [RFC5226].
This document defines five statistics types for statistics reporting This document defines five statistics types for statistics reporting
(Section 2.2): (Section 2.2):
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.
skipping to change at page 10, line 4 skipping to change at page 10, line 39
policy defined in [RFC5226]. policy defined in [RFC5226].
This document defines five statistics types for statistics reporting This document defines five statistics types for statistics reporting
(Section 2.2): (Section 2.2):
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.
Stat Type values 5 through 32767 MUST be assigned using the "IETF Stat Type values 5 through 32767 MUST be assigned using the "IETF
Consensus" policy, and values 32768 through 65535 using the "First Consensus" policy, and values 32768 through 65535 using the "First
Come First Served" policy, defined in [RFC5226]. Come First Served" policy, defined in [RFC5226].
7. Security Considerations 8. Security Considerations
This document defines a mechanism to obtain a full dump or provide This document defines a mechanism to obtain a full dump or provide
continuous monitoring of a BGP speaker's local BGP table, including continuous monitoring of a BGP speaker's local BGP table, including
received BGP messages. This capability could allow an outside party received BGP messages. This capability could allow an outside party
to obtain information not otherwise obtainable. to obtain information not otherwise obtainable.
Implementations of this protocol MUST require manual configuration of Implementations of this protocol MUST require manual configuration of
the monitored and monitoring devices. the monitored and monitoring devices.
Users of this protocol MAY use some type of secure transmission Users of this protocol MAY use some type of secure transmission
mechanism, such as IPSec [RFC4303], to transmit this data. mechanism, such as IPSec [RFC4303], to transmit this data.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informative References 9.2. Informative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
Appendix A. Changes Between BMP Versions 1 and 2
o Added Peer Up Message
o Added L flag
o Editorial changes
Authors' Addresses Authors' Addresses
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: jgs@juniper.net Email: jgs@juniper.net
Rex Fernando Rex Fernando
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: rex@juniper.net Email: rex@juniper.net
Stephen Stuart Stephen Stuart
Google Google
 End of changes. 32 change blocks. 
36 lines changed or deleted 95 lines changed or added

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