draft-ietf-grow-bmp-02.txt   draft-ietf-grow-bmp-03.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: January 14, 2010 S. Stuart Expires: June 17, 2010 S. Stuart
Google Google
July 13, 2009 December 14, 2009
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-02 draft-ietf-grow-bmp-03
Abstract
This document proposes a simple protocol, BMP, which can be used to
monitor BGP sessions. BMP is intended to provide a more convenient
interface for obtaining route views for research purpose than the
screen-scraping approach in common use today. 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.
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. This document may contain material provisions of BCP 78 and BCP 79.
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 January 14, 2010. This Internet-Draft will expire on June 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document proposes a simple protocol, BMP, which can be used to This document may contain material from IETF Documents or IETF
monitor BGP sessions. BMP is intended to provide a more convenient Contributions published or made publicly available before November
interface for obtaining route views for research purpose than the 10, 2008. The person(s) controlling the copyright in some of this
screen-scraping approach in common use today. The design goals are material may not have granted the IETF Trust the right to allow
to keep BMP simple, useful, easily implemented, and minimally modifications of such material outside the IETF Standards Process.
service-affecting. BMP is not suitable for use as a routing Without obtaining an adequate license from the person(s) controlling
protocol. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6 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 2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8
3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9
4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 11 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Many researchers wish to have access to the contents of routers' BGP Many researchers wish to have access to the contents of routers' BGP
RIBs as well as a view of protocol updates that the router is RIBs as well as a view of protocol updates that the router is
receiving. This monitoring task cannot be realized by standard receiving. This monitoring task cannot be realized by standard
protocol mechanisms. At present, this data can only be obtained protocol mechanisms. At present, this data can only be obtained
through screen-scraping. through screen-scraping.
The BMP protocol provides access to the Adj-RIB-In of a peer on an The BMP protocol provides access to the Adj-RIB-In of a peer on an
skipping to change at page 4, line 21 skipping to change at page 5, line 21
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. BMP Message Format 2. BMP Message Format
The following common header appears in all BMP messages. The rest of The following common header appears in all BMP messages. The rest of
the data in a BMP message is dependent on the "Message Type" field in the data in a BMP message is dependent on the "Message Type" field in
the common header. the common header.
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg. Type | Peer Type | Peer Flags | | Version | Message Length | Msg. Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Distinguisher (present based on peer type) | | Peer Distinguisher (present based on peer type) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) | | Peer Address (16 bytes) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS | | Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID | | Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) | | Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) | | Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Version (1 byte): Indicates the BMP version. This is set to '2' o Version (1 byte): Indicates the BMP version. This is set to '3'
for all messages defined in this specification. for all messages defined in this specification.
o Message Length (2 bytes): Length of the message in bytes
(including headers, data and encapsulated messages, if any).
o Message Type (1 byte): This identifies the type of the BMP o Message Type (1 byte): This identifies the type of the BMP
message, message. A BMP implementation MUST ignore unrecognized message
types upon receipt.
* 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 * Type = 3: Peer Up Notification
o Peer Type (1 byte): These bits identify the type of the peer. o Peer Type (1 byte): These bits identify the type of the peer.
Currently only two types of peers are identified, Currently only two types of peers are identified,
* Peer Type = 0: Global Instance Peer * Peer Type = 0: Global Instance Peer
* Peer Type = 1: L3 VPN Instance Peer * Peer Type = 1: L3 VPN Instance Peer
o Peer Flags (1 byte): These flags provide more information about o Peer Flags (1 byte): These flags provide more information about
the peer. The flags are defined as follows. the peer. The flags are defined as follows.
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L| Reserved | |V|L| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 6, line 14 skipping to change at page 7, line 22
unavailable. Precision of the timestamp is implementation- unavailable. Precision of the timestamp is implementation-
dependent. 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.
can be determined by parsing it in the normal fashion as specified in
[RFC4271].
2.2. Stats Reports 2.2. Stats Reports
These messages contain information that could be used by the These messages contain information that could be used by the
monitoring station to observe interesting events that occur on the monitoring station to observe interesting events that occur on the
router. 'Stats Report' messages have a message type of '3'. router. 'Stats Report' messages have a message type of '3'.
The transmission of the SR messages could be timer triggered or event The transmission of the SR messages could be timer triggered or event
driven (for example, when a significant event occurs or a threshold driven (for example, when a significant event occurs or a threshold
is reached). This specification does not impose any timing is reached). This specification does not impose any timing
skipping to change at page 7, line 12 skipping to change at page 8, line 18
| Stat Data | | Stat Data |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Stat Type (2 bytes): Defines the type of the statistic carried in o Stat Type (2 bytes): Defines the type of the statistic carried in
the "Stat Data" field. the "Stat Data" field.
o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. o Stat Len (2 bytes): Defines the length of the "Stat Data" Field.
This specification defines the following statistics. All statistics This specification defines the following statistics. All statistics
are 4-byte quantities and the stats data are counters. are 4-byte quantities and the stats data are counters. A BMP
implementation MUST ignore unrecognized stat types on receipt, and
likewise MUST ignore unexpected data in the Stat Data field.
o Stat Type = 0: Number of prefixes rejected by inbound policy. o Stat Type = 0: Number of prefixes rejected by inbound policy.
o Stat Type = 1: Number of (known) duplicate prefix advertisements. o Stat Type = 1: Number of (known) duplicate prefix advertisements.
o Stat Type = 2: Number of (known) duplicate withdraws. o Stat Type = 2: Number of (known) duplicate withdraws.
o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST
loop. loop.
o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. o Stat Type = 4: Number of updates invalidated due to AS_PATH loop.
o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
o Stat Type = 6: Number of updates invalidated due to AS_CONFED
loop.
Note that the current specification only specifies 4-byte counters as Note that the current specification only specifies 4-byte counters as
"Stat Data". This does not preclude future versions from "Stat Data". This does not preclude future versions from
incorporating more complex TLV-type "Stat Data" (for example, one incorporating more complex TLV-type "Stat Data" (for example, one
which can carry prefix specific data). SR messages are optional. which can carry prefix specific data). SR messages are optional.
However if an SR message is transmitted, this specification requires However if an SR message is transmitted, this specification requires
at least one statistic to be carried in it. at least one statistic to be carried in it.
2.3. Peer Down Notification 2.3. Peer Down Notification
This message is used to indicate that a peering session was This message is used to indicate that a peering session was
terminated. The type of this message is 4. terminated. The type of this message is 4.
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 | Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Message (present if Reason = 1 or 3) | | Data (present if Reason = 1, 2 or 3) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason indicates why the session was closed. Defined values are: Reason indicates why the session was closed. Defined values are:
o Reason 1: The local system closed the session. Following the o Reason 1: The local system closed the session. Following the
Reason is a BGP PDU containing a BGP NOTIFICATION message that Reason is a BGP PDU containing a BGP NOTIFICATION message that
would have been sent to the peer. The length of the PDU can be would have been sent to the peer.
determined by parsing it in the normal fashion as specified in
[RFC4271].
o Reason 2: The local system closed the session. No notification o Reason 2: The local system closed the session. No notification
message was sent. message was sent. Following the reason code is a two-byte field
containing the code corresponding to the FSM Event which caused
the system to close the session (see Section 8.1 of [RFC4271]).
Zero is used to indicate that no relevant Event code is defined.
o Reason 3: The remote system closed the session with a notification o Reason 3: The remote system closed the session with a notification
message. Following the Reason is a BGP PDU containing the BGP message. Following the Reason is a BGP PDU containing the BGP
NOTIFICATION message as received from the peer. The length of the NOTIFICATION message as received from the peer.
PDU can be determined by parsing it in the normal fashion as
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 2.4. Peer Up Notification
The Peer Up message is used to indicate that a peering session has The Peer Up message is used to indicate that a peering session has
come up (i.e., has transitioned into ESTABLISHED state). Following come up (i.e., has transitioned into ESTABLISHED state). Following
the common BMP header are the full OPEN messages as sent and received the common BMP header is the following:
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 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
plus the lengths of the two encapsulated OPEN messages which can be +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
determined by parsing them in the normal fashion as specified in | Local Address (16 bytes) |
[RFC4271]. ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | Remote Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sent OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Received OPEN Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Local Address: The local IP address associated with the peering
TCP session. It is 4 bytes long if an IPv4 address is carried in
this field, as determined by the V flag (with most significant
bytes zero filled) and 16 bytes long if an IPv6 address is carried
in this field.
o Local Port: The local port number associated with the peering TCP
session.
o Remote Port: The remote port number associated with the peering
TCP session. (Note that the remote address can be found in the
Peer Address field of the fixed header.)
o Sent OPEN Message: The full OPEN message transmitted by the
monitored router to its peer.
o Received OPEN Message: The full OPEN message received by the
monitored router from its peer.
3. Route Monitoring 3. Route Monitoring
After the BMP session is up, Route Monitoring messages are used to After the BMP session is up, Route Monitoring messages are used to
provide a snapshot of the Adj-RIB-In of a particular peer. It does provide a snapshot of the Adj-RIB-In of a particular peer. 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
skipping to change at page 10, line 40 skipping to change at page 12, line 31
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.
o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID.
o Stat Type = 6: Number of updates invalidated due to AS_CONFED
loop.
Stat Type values 5 through 32767 MUST be assigned using the "IETF Stat Type values 7 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].
8. Security Considerations 8. Security Considerations
This document defines a mechanism to obtain a full dump or provide This document defines a mechanism to obtain a full dump or provide
continuous monitoring of a BGP speaker's local BGP table, including continuous monitoring of a BGP speaker's local BGP table, including
received BGP messages. This capability could allow an outside party received BGP messages. This capability could allow an outside party
to obtain information not otherwise obtainable. to obtain information not otherwise obtainable.
skipping to change at page 11, line 39 skipping to change at page 13, line 34
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
Appendix A. Changes Between BMP Versions 1 and 2 Appendix A. Changes Between BMP Versions 1 and 2
o Added Peer Up Message o Added Peer Up Message
o Added L flag o Added L flag
o Editorial changes o Editorial changes
Appendix B. Changes Between BMP Versions 2 and 3
o Added a 16-bit length field to the fixed header.
o Clarified error handling.
o Added stat types 5 and 6 (number of updates invalidated due to
ORIGINATOR_ID and AS_CONFED, respectively).
o For peer down messages, the relevant FSM event is to be sent in
type 2 messages.
o Added local address and local and remote ports to the peer up
message.
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. 26 change blocks. 
63 lines changed or deleted 121 lines changed or added

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