--- 1/draft-ietf-grow-bmp-02.txt 2009-12-14 11:12:34.000000000 +0100 +++ 2/draft-ietf-grow-bmp-03.txt 2009-12-14 11:12:34.000000000 +0100 @@ -1,95 +1,102 @@ Network Working Group J. Scudder Internet-Draft R. Fernando Intended status: Standards Track Juniper Networks -Expires: January 14, 2010 S. Stuart +Expires: June 17, 2010 S. Stuart Google - July 13, 2009 + December 14, 2009 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 This Internet-Draft is submitted to IETF in full conformance with the - 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. + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 14, 2010. + This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + 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 - 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. + 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 6 2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7 2.4. Peer Up Notification . . . . . . . . . . . . . . . . . . . 8 - 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 12 + Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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 receiving. This monitoring task cannot be realized by standard protocol mechanisms. At present, this data can only be obtained through screen-scraping. The BMP protocol provides access to the Adj-RIB-In of a peer on an @@ -142,50 +149,57 @@ document are to be interpreted as described in RFC 2119 [RFC2119]. 2. BMP Message Format The following common header appears in all BMP messages. The rest of the data in a BMP message is dependent on the "Message Type" field in the common header. 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 Address (16 bytes) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer BGP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. + o Message Length (2 bytes): Length of the message in bytes + (including headers, data and encapsulated messages, if any). + o Message Type (1 byte): This identifies the type of the BMP - message, + message. A BMP implementation MUST ignore unrecognized message + types upon receipt. * Type = 0: Route Monitoring * Type = 1: Statistics Report * Type = 2: Peer Down Notification * Type = 3: Peer Up Notification o Peer Type (1 byte): These bits identify the type of the peer. Currently only two types of peers are identified, + * Peer Type = 0: Global Instance Peer * Peer Type = 1: L3 VPN Instance Peer o Peer Flags (1 byte): These flags provide more information about the peer. The flags are defined as follows. 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |V|L| Reserved | +-+-+-+-+-+-+-+-+ @@ -228,23 +242,21 @@ unavailable. Precision of the timestamp is implementation- dependent. 2.1. Route Monitoring Route Monitoring messages are used for initial synchronization of ADJ-RIB-In. They are also used for ongoing monitoring of received advertisements and withdraws. This is discussed in more detail in subsequent sections. - 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 - [RFC4271]. + Following the common BMP header is a BGP PDU. 2.2. Stats Reports These messages contain information that could be used by the monitoring station to observe interesting events that occur on the router. 'Stats Report' messages have a message type of '3'. The transmission of the SR messages could be timer triggered or event driven (for example, when a significant event occurs or a threshold is reached). This specification does not impose any timing @@ -272,86 +283,117 @@ | Stat Data | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Stat Type (2 bytes): Defines the type of the statistic carried in 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 - 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 = 1: Number of (known) duplicate prefix advertisements. o Stat Type = 2: Number of (known) duplicate withdraws. o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 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 "Stat Data". This does not preclude future versions from incorporating more complex TLV-type "Stat Data" (for example, one which can carry prefix specific data). SR messages are optional. However if an SR message is transmitted, this specification requires at least one statistic to be carried in it. 2.3. Peer Down Notification This message is used to indicate that a peering session was terminated. The type of this message is 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 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: o Reason 1: The local system closed the session. Following the Reason is a BGP PDU containing a BGP NOTIFICATION message that - would have been sent to the peer. The length of the PDU can be - determined by parsing it in the normal fashion as specified in - [RFC4271]. + would have been sent to the peer. 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 message. Following the Reason is a BGP PDU containing the BGP - NOTIFICATION message as received from the peer. The length of the - PDU can be determined by parsing it in the normal fashion as - specified in [RFC4271]. + NOTIFICATION message as received from the peer. o Reason 4: The remote system closed the session without a 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 common BMP header is the following: - 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]. + 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Address (16 bytes) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Port | Remote Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sent OPEN Message | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Received OPEN Message | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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 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 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 ordering of messages in the peer dump. Depending on the implementation or configuration, it may only be @@ -440,22 +482,25 @@ This document defines five statistics types for statistics reporting (Section 2.2): o Stat Type = 0: Number of prefixes rejected by inbound policy. o Stat Type = 1: Number of (known) duplicate prefix advertisements. o Stat Type = 2: Number of (known) duplicate withdraws. o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 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 Come First Served" policy, defined in [RFC5226]. 8. Security Considerations This document defines a mechanism to obtain a full dump or provide continuous monitoring of a BGP speaker's local BGP table, including received BGP messages. This capability could allow an outside party to obtain information not otherwise obtainable. @@ -486,29 +531,41 @@ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 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 +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 John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: jgs@juniper.net + Rex Fernando Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: rex@juniper.net Stephen Stuart Google