Advanced BGP Monitoring Protocol (BMP) Statistics Types Hewlett Packard Enterprise
10 Technology Park Dr Westford MA 01886 United States of America mukul.srivastava@hpe.com
China Mobile
32 Xuanwumen West Street Beijing Xicheng District 100053 China liuyisong@chinamobile.com
New H3C Technologies
8 Yongjia North Road Beijing Haidian District 100094 China linchangwang.04414@h3c.com
China Mobile
32 Xuanwumen West Street Beijing Xicheng District 100053 China lijinming@chinamobile.com
OPS grow IDR GROW BGP BMP The BGP Monitoring Protocol (BMP) described in RFC 7854 defines statistics message types to observe events that occur on a monitored router. This document defines new statistics types to monitor BMP Adj‑RIB‑In and Adj‑RIB‑Out Routing Information Bases (RIBs).
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2026 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. 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
  • .  Terminology
  • .  RIB Monitoring Statistics
    • .  Statistics Format
    • .  Adj‑RIB‑In RIB Monitoring Statistics Definition
    • .  Adj‑RIB‑Out RIB Monitoring Statistics Definition
  • .  Application Scope of Statistics
  • .  Implementation Considerations
  • .  Operational Considerations
  • .  Security Considerations
  • .  IANA Considerations
  • .  Normative References
  • Acknowledgements
  • Authors' Addresses
Introduction defines a number of different BGP Monitoring Protocol (BMP) statistics types to observe major events that occur on a monitored router. Statistics are either counters or Gauges. also defines several BMP statistics types for Adj‑RIB‑Out of a monitored router. New BMP statistics types are needed to enable more-refined BGP route monitoring and analysis to improve operational maintenance and troubleshooting capabilities. This document defines Gauges for new BMP statistics. The applicability scope of these new Gauges (Adj‑RIB‑In, Adj‑RIB‑Out, Loc-RIB) is provided in . The format of the BMP Statistics Report message remains the same as defined in .
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Terminology This document makes use of the following terms:
Adj‑RIB‑In:
As defined in :
The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers.
Pre-policy Adj‑RIB‑In:
The result before applying the inbound policy to an Adj‑RIB‑In. Note that this is an explicit definition that aligns with the pre-policy Adj‑RIB‑In concept specified in .
Post-policy Adj‑RIB‑In:
As defined in :
The result of applying inbound policy to an Adj‑RIB‑In, but prior to the application of route selection to form the Loc-RIB.
Adj‑RIB‑Out:
As defined in :
The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages.
Pre-policy Adj‑RIB‑Out:
As defined in :
The result before applying the outbound policy to an Adj‑RIB‑Out. This normally would match what is in the local RIB.
Post-policy Adj‑RIB‑Out:
As defined in :
The result of applying outbound policy to an Adj‑RIB‑Out. This MUST convey to the BMP receiver what is actually transmitted to the peer.
Loc-RIB:
As defined in :
The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.
Note that the Loc-RIB state as monitored through BMP might also contain routes imported from other routing protocols such as an IGP or local static routes.
Route:
As defined in :
A unit of information that pairs a set of destinations with the attributes of a path to those destinations.
The terms "producer" and "collector" are equivalent to "monitored router" and "monitoring station", respectively. Also, "implementation" follows the same usage as in .
RIB Monitoring Statistics This section defines different statistics types for Adj‑RIB‑In and Adj‑RIB‑Out monitoring types. Some of these statistics are also applicable to Loc-RIB; refer to for more details.
Statistics Format The BMP Statistics Report message carries statistic information in Type-Length-Value (TLV) formats. Each statistic is encoded as a TLV (Stat Type, Stat Len, Stat Data) (see ). "Stat Data" is being referred to as "value" when defining various RIB Monitoring Statistics. Statistics defined in this document can be categorized into two granularities: Global Statistics and Per-AFI/SAFI (see ) Statistics. Statistics defined with Per-AFI/SAFI descriptions belong to Per-AFI/SAFI Statistics, while other statistics belong to Global Statistics. Both Global Statistics and their corresponding Per-AFI/SAFI Statistics can be reported simultaneously. The Per-AFI/SAFI Statistics apply only to the AFI/SAFI that a BGP speaker supports and negotiates with its peer. The authoritative registries for AFI/SAFI values are maintained by IANA (see and ). For Global Statistics, the "Stat Data" (value) field is a single 64-bit unsigned integer Gauge where the "Stat Len" field MUST be set to 8. Each global statistic MUST appear only once in a BMP Statistics Report message. For Per-AFI/SAFI Statistics, the "Stat Data" (value) field is a 11-byte structured value formatted as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge. The "Stat Len" MUST be set to 11. For any given per-AFI/SAFI Statistic, duplicate (AFI, SAFI) pairs MUST NOT appear within the same BMP Statistics Report message. Per-AFI/SAFI statistics MUST NOT be included in the BMP Statistics Report message if there is no data to report for that AFI/SAFI. If statistics apply to the Loc-RIB, the "Peer Type" field in the Per-Peer Header of the corresponding BMP Statistics Report message MUST be set to 3 (Loc-RIB Instance Peer) . Otherwise, the "Peer Type" field MUST be set as defined in . A BMP implementation MUST ignore unrecognized Stat Types upon receipt.
Adj‑RIB‑In RIB Monitoring Statistics Definition
Type = 18: (64-bit Gauge)
Current number of routes in the pre-policy Adj‑RIB‑In. This Gauge is similar to Stat Type 7 defined in and makes it explicitly for the pre-policy Adj‑RIB‑In.
Type = 19: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI pre-policy Adj‑RIB‑In. This Gauge is similar to Stat Type 9 defined in and makes it explicitly for the pre-policy Adj‑RIB‑In. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 20: (64-bit Gauge)
Current number of routes in the post-policy Adj‑RIB‑In.
Type = 21: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 22: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI pre-policy Adj‑RIB‑In rejected by an inbound policy. This Gauge is different from Stat Type 0 defined in . Stat Type 0 is a 32-bit counter that is a monotonically increasing number; the Stat Type 22 is a 64-bit Gauge that represents the current number of routes rejected by an inbound policy due to ongoing policy configuration changes. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 23: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In accepted by an inbound policy. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 26: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB suppressed by a configured route-damping policy. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge. 'Suppressed' refers to a route that has been declared suppressed by the BGP Route Flap Damping mechanism as described in .
Type = 27: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB marked as stale by Graceful Restart (GR) events. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge. 'Stale' refers to a route that has been declared stale by the BGP GR mechanism as described in .
Type = 28: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB marked as stale by Long-Lived Graceful Restart (LLGR). The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge. 'Stale' refers to a route that has been declared stale by the BGP LLGR mechanism as described in .
Type = 29: (64-bit Gauge)
Current number of routes in the post-policy Adj‑RIB‑In left before exceeding the received-route threshold as defined in .
Type = 30: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI in post-policy Adj‑RIB‑In left before exceeding the received-route threshold that corresponds to the upper bound of per-AFI/SAFI accepted routes following the model defined in . The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 31: (64-bit Gauge)
Current number of routes in the post-policy Adj‑RIB‑In or Loc-RIB left before exceeding a license-customized route threshold. If no such license is configured, or if the license does not impose a hard limit, this value MUST NOT be reported.
Type = 32: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB left before exceeding a license-customized route threshold. If no such license is configured, or if the license does not impose a hard limit, this value MUST NOT be reported. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 33: (64-bit Gauge)
Current number of routes in the pre-policy Adj‑RIB‑In rejected due to exceeding the maximum AS_PATH length supported by the local configuration.
Type = 34: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI in pre-policy Adj‑RIB‑In rejected due to exceeding the maximum AS_PATH length supported by the local configuration. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 35: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In invalidated after verifying the route origin Autonomous System Number (ASN) through the Route Origin Authorization (ROA) of the Resource Public Key Infrastructure (RPKI) . This is the total number of routes invalidated due to a mismatch of origin ASNs and a mismatch of prefix length. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 36: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In validated after verifying the route origin ASN through the ROA of the RPKI . The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 37: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑In whose RPKI route origin validation state is NotFound due to the absence of a matching ROA of RPKI . The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Adj‑RIB‑Out RIB Monitoring Statistics Definition
Type = 38: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI pre-policy Adj‑RIB‑Out rejected by an outbound policy. These routes are active routes that otherwise would have been advertised in the absence of an outbound policy that rejected them. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 39: (64-bit Gauge)
Current number of routes in the pre-policy Adj‑RIB‑Out filtered due to the AS_PATH length exceeding the locally configured maximum.
Type = 40: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI pre-policy Adj‑RIB‑Out filtered due to AS_PATH length exceeding the locally configured maximum. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 41: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑Out invalidated after verifying the route origin ASN through the ROA of the RPKI . This is the total number of routes invalidated due to a mismatch of origin ASNs and a mismatch of prefix lengths. The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 42: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑Out validated after verifying the route origin ASN through the ROA of the RPKI . The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Type = 43: (64-bit Gauge)
Current number of routes in the per-AFI/SAFI post-policy Adj‑RIB‑Out whose RPKI route origin validation state is NotFound due to the absence of a matching ROA of RPKI . The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.
Application Scope of Statistics briefly lists the statistics defined in this document and outlines their scope of application. Scope of Application
Type Pre-policy Adj‑RIB‑In Post-policy Adj‑RIB‑In Loc-RIB Pre-policy Adj‑RIB‑Out Post-policy Adj‑RIB‑Out
18 Y N N N N
19 Y N N N N
20 N Y N N N
21 N Y N N N
22 Y N N N N
23 N Y N N N
26 N Y Y N N
27 N Y Y N N
28 N Y Y N N
29 N Y N N N
30 N Y N N N
31 N Y Y N N
32 N Y Y N N
33 Y N N N N
34 Y N N N N
35 N Y N N N
36 N Y N N N
37 N Y N N N
38 N N N Y N
39 N N N Y N
40 N N N Y N
41 N N N N Y
42 N N N N Y
43 N N N N Y
Implementation Considerations This document specifies Gauges for new BMP statistics. The format of BMP Statistics Report messages remains unchanged from . This section outlines the implementation considerations for new BMP statistics. For backward compatibility, and absent any other policy, it is RECOMMENDED that BMP producers capable of generating both (Types 7 and 18) and (Types 9 and 19) BMP statistics transmit both corresponding types simultaneously. This allows BMP collectors to process either format according to their needs without disrupting existing implementations that rely on Types 7 or 9. The selection of which statistics types to generate within each pair SHOULD be treated as an implementation decision rather than a protocol requirement, with the BMP collector behavior for handling these statistics types remaining implementation specific. Some statistics are dependent on feature configurations, such as GR, LLGR, and RPKI; therefore, the corresponding statistics SHOULD only be generated and sent when these features are enabled on the BMP producer. These statistics include the following Types: 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 39, 40, 41, 42, and 43. Some statistics are also relevant for the Loc-RIB view ; therefore, they may apply to the Loc-RIB view after best-path selection is completed. These statistics include Types 26, 27, 28, 31, and 32. When these statistics apply to the Loc-RIB view, the "Peer Type" field in the Per-Peer Header of the corresponding BMP Statistics Report message MUST set to 3. Certain statistics may have logical relationships (e.g., per-AFI/SAFI counts summing to global totals). BMP statistics producers and collectors MAY perform consistency checks but MUST NOT assume strict dependencies (due to potential race conditions or partial failures). Discrepancies (e.g., sum(per-AFI/SAFI) != global count) SHOULD be logged as warnings but MUST NOT disrupt protocol operation. The generation and transmission of Types 27 and 28 during an active GR/LLGR event consumes additional control plane resources (e.g., CPU). BMP statistics producers SHOULD prioritize the core GR/LLGR convergence procedures. To avoid adversely impacting the restart process, a BMP statistics producer MAY choose to sample this value at a lower frequency, buffer the updates, or temporarily suspend reporting for this type during the most critical phases of a switchover. These Gauges may reset due to manual clearance or overflow. BMP statistics producers and collectors MUST track discontinuities and log this anomaly.
Operational Considerations This section outlines some operational considerations of new BMP statistics for BMP operators. Transmission scheduling and triggering mechanisms for new Gauges are implementation dependent. BMP operators SHOULD determine appropriate report generation and delivery strategies, including configurable timing intervals and threshold values. The mechanism for controlling the reporting of new Gauges SHOULD be consistent with that of existing types. BMP operators SHOULD rate-limit statistics updates to minimize performance impact on control plane processes. BMP operators SHOULD only enable necessary statistics to reduce memory and CPU overhead. Implementations SHOULD also support per-router configuration of statistic subsets for collection and reporting. Some BMP statistics producers, or configurations in BMP statistics producers, MAY discard routes that do not match policy; thus, the accepted count (Type 23) and the Adj‑RIB‑In counts (Type 21) will be identical in such cases. BMP operators SHOULD be aware of this behavior when interpreting these Gauges. BMP operators SHOULD be aware that BMP statistics producers and collectors MAY log inconsistencies between statistics as warnings.
Security Considerations Procedures and protocol extensions defined in this document do not affect the BMP security model. All security and authentication mechanisms required by , , and are also applicable to the Gauges defined in this document. This document does not add any additional security considerations. Monitored devices SHOULD be configured to implement rate-limited reporting of new Gauges.
IANA Considerations IANA has assigned the following new parameters in the "BMP Statistics Types" registry, part of the "BGP Monitoring Protocol (BMP) Parameters" registry group. IANA has listed these entries as follows. This document serves as a reference for each entry. BMP Statistics Types
Stat Type Description
18 Number of routes currently in the pre-policy Adj‑RIB‑In.
19 Number of routes currently in the per-AFI/SAFI pre-policy Adj‑RIB‑In.
20 Number of routes currently in the post-policy Adj‑RIB‑In.
21 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In.
22 Number of routes currently in the per-AFI/SAFI pre-policy Adj‑RIB‑In rejected by an inbound policy.
23 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In accepted by an inbound policy.
26 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB suppressed by a configured route-damping policy.
27 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB marked as stale by GR events.
28 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB marked as stale by LLGR.
29 Number of routes currently in the post-policy Adj‑RIB‑In left before exceeding the received-route threshold.
30 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In left before exceeding the received-route threshold.
31 Number of routes currently in the post-policy Adj‑RIB‑In or Loc-RIB left before exceeding a license-customized route threshold.
32 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In or Loc-RIB left before exceeding a license-customized route threshold.
33 Number of routes currently in the pre-policy Adj‑RIB‑In rejected due to exceeding the locally configured maximum AS_PATH length.
34 Number of routes currently in the per-AFI/SAFI pre-policy Adj‑RIB‑In rejected due to exceeding the locally configured maximum AS_PATH length.
35 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In invalidated after verifying the route origin ASN through the ROA of the RPKI and mismatch of prefix length.
36 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In validated after verifying the route origin ASN through the ROA of the RPKI.
37 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑In whose RPKI route origin validation state is NotFound.
38 Number of routes currently in the per-AFI/SAFI pre-policy Adj‑RIB‑Out rejected by an outbound policy.
39 Number of routes currently in the pre-policy Adj‑RIB‑Out filtered due to AS_PATH length exceeding the locally configured maximum.
40 Number of routes currently in the per-AFI/SAFI pre-policy Adj‑RIB‑Out filtered due to AS_PATH length exceeding the locally configured maximum.
41 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑Out invalidated after verifying the route origin ASN through the ROA of the RPKI and mismatch of prefix length.
42 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑Out validated after verifying the route origin ASN through the ROA of the RPKI.
43 Number of routes currently in the per-AFI/SAFI post-policy Adj‑RIB‑Out whose RPKI route origin validation state is NotFound.
Normative References Address Family Numbers IANA Subsequent Address Family Identifiers (SAFI) Parameters IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BGP Route Flap Damping A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK] A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Graceful Restart Mechanism for BGP This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK] Multiprotocol Extensions for BGP-4 This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] BGP Prefix Origin Validation To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] BGP Monitoring Protocol (BMP) This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out. Support for Local RIB in the BGP Monitoring Protocol (BMP) The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. Long-Lived Graceful Restart for BGP This document introduces a BGP capability called the "Long-Lived Graceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called "NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is. This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.
Acknowledgements The authors would like to thank , , , and for their valuable input. Thanks to for the OPSDIR, for the GENART, and for the RTGDIR review. Thanks to , , and for the IESG review.
Authors' Addresses Hewlett Packard Enterprise
10 Technology Park Dr Westford MA 01886 United States of America mukul.srivastava@hpe.com
China Mobile
32 Xuanwumen West Street Beijing Xicheng District 100053 China liuyisong@chinamobile.com
New H3C Technologies
8 Yongjia North Road Beijing Haidian District 100094 China linchangwang.04414@h3c.com
China Mobile
32 Xuanwumen West Street Beijing Xicheng District 100053 China lijinming@chinamobile.com