Requirements for Monitoring RPKI-Related Processes on Routers Using BMP
draft-wang-grow-bmp-rpki-mon-reqs-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Shuhe Wang , Mingwei Xu , Yangyang Wang , Jia Zhang | ||
| Last updated | 2026-05-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-grow-bmp-rpki-mon-reqs-03
GROW S. Wang
Internet-Draft M. Xu
Intended status: Informational Y. Wang
Expires: 2 December 2026 J. Zhang
Beijing Zhongguancun Laboratory
31 May 2026
Requirements for Monitoring RPKI-Related Processes on Routers Using BMP
draft-wang-grow-bmp-rpki-mon-reqs-03
Abstract
This document outlines requirements for extending the BGP Monitoring
Protocol (BMP) to provide comprehensive monitoring of RPKI-related
processes on routers, including RPKI data acquisition, RPKI-related
policy configuration, route validation, and the impact of validation
on routing decisions. The proposed extensions aim to standardize
router-side monitoring of RPKI within BMP, focusing specifically on
RPKI's effect on BGP routing decisions while maintaining a clear
scope boundary with other monitoring mechanisms such as YANG modeling
and streaming telemetry for RPKI-to-Router (RTR) protocol operations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 2 December 2026.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Wang, et al. Expires 2 December 2026 [Page 1]
Internet-Draft BMP-RPKI-MON-REQS May 2026
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Overview . . . . . . . . . . . . . . . . . . . . 3
3.1. RPKI Data Acquisition . . . . . . . . . . . . . . . . . . 4
3.2. RPKI Policy Configuration . . . . . . . . . . . . . . . . 4
3.3. Route Validation with RPKI . . . . . . . . . . . . . . . 4
3.4. Impact of RPKI Validation on Routing . . . . . . . . . . 4
4. RPKI Configuration Monitoring . . . . . . . . . . . . . . . . 5
4.1. RPKI Data Source Status . . . . . . . . . . . . . . . . . 5
4.2. RPKI Policy Configuration . . . . . . . . . . . . . . . . 6
4.3. RPKI_CONFIG Message Format . . . . . . . . . . . . . . . 7
5. Route Validation with RPKI . . . . . . . . . . . . . . . . . 8
5.1. Validation Statistics . . . . . . . . . . . . . . . . . . 8
5.2. Per-Route Validation Report . . . . . . . . . . . . . . . 8
6. Impact of RPKI Validation on Routing . . . . . . . . . . . . 9
7. Relationship with Other Monitoring Mechanisms . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Transmission Security . . . . . . . . . . . . . . . . . . 11
8.2. Operational Security . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The Resource Public Key Infrastructure (RPKI) enhances BGP security
by enabling cryptographic validation of route origins [RFC6483]
[RFC6811] and AS paths [I-D.ietf-sidrops-aspa-verification]. Despite
growing adoption of RPKI, standard implementations of the BGP
Monitoring Protocol (BMP) [RFC7854] do not natively support
monitoring of RPKI-related data. This limitation hampers visibility
into RPKI validation processes and their impact on network
operations.
While existing proposals aim to extend BMP for specific aspects of
RPKI monitoring, such as reporting invalid routes
[I-D.ietf-grow-bmp-path-marking-tlv] [I-D.ietf-grow-bmp-rel] or
providing validation statistics [I-D.ietf-grow-bmp-bgp-rib-stats], a
Wang, et al. Expires 2 December 2026 [Page 2]
Internet-Draft BMP-RPKI-MON-REQS May 2026
comprehensive and end-to-end monitoring framework for the RPKI
lifecycle on the router is still lacking. This document defines
requirements and extensions for BMP to monitor four key stages:
* Acquisition of RPKI data;
* Configuration of RPKI policies;
* Validation of routes using RPKI;
* Impact of RPKI validation on routing decisions.
It is important to note that this document focuses on monitoring
RPKI's effect on BGP routing decisions, not on replicating the
operational monitoring of the RTR protocol itself. Operational
aspects of RTR — such as session management, protocol version
negotiation, cache server health, and synchronization sequence
numbers — are better served by YANG modeling and streaming telemetry
mechanisms. BMP and YANG/telemetry are complementary: YANG handles
RTR protocol operations, while BMP (as extended by this document)
handles the impact of RPKI data on BGP route validation and
selection. Section 7 discusses this scope boundary in more detail.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Requirements Overview
The BMP extension for RPKI monitoring SHOULD:
* Monitor extensible RPKI data from various sources on routers,
including through RPKI-to-Router Protocol (RTR) [RFC8210], BGP
[RFC4271], static configurations, or SLURM local exceptions
[RFC8416];
* Enable real-time monitoring of the route validation process on the
router [RFC6811];
* Facilitate the correlation between RPKI validation states and BGP
routing decisions;
* Scale efficiently across diverse validation types.
Wang, et al. Expires 2 December 2026 [Page 3]
Internet-Draft BMP-RPKI-MON-REQS May 2026
Consequently, this document identifies four key stages in the RPKI
lifecycle on routers which necessitate detailed monitoring and
reporting:
3.1. RPKI Data Acquisition
To ensure accurate and timely acquisition of RPKI data, network
administrators require BMP to provide real-time, consistent
monitoring of the health and status of all RPKI data sources. These
sources include RTR connections to RPKI caches, iBGP and eBGP peers,
local static configurations, and SLURM local exceptions [RFC8416].
This enables rapid detection and response to faults or outages in
data provisioning. Accordingly, BMP SHOULD report a common set of
source-type-agnostic status fields for each source, with source-type-
specific parameters available as optional extensions.
3.2. RPKI Policy Configuration
Routing policies on the router may change dynamically, therefore
real-time monitoring is necessary to ensure correct implementation
and prompt misconfiguration detection of RPKI-based policies. To
achieve this, BMP SHOULD report global RPKI enforcement status, RPKI-
related validation rules and policies for each peer, and any SLURM
local exceptions [RFC8416] that modify the effective validation
dataset.
3.3. Route Validation with RPKI
Routers from different vendors implement RPKI-based route validation
— including origin validation and path validation — with varying
approaches. To facilitate accurate troubleshooting against
validation outcomes, BMP SHOULD report the RPKI validation state as
well as the related rules that contribute to the state.
3.4. Impact of RPKI Validation on Routing
A router may implement numerous routing policies, resulting in
complex routing behavior that obscures the influence of RPKI
validation on decision-making. To provide visibility into this
impact, BMP should report both intended outcomes and unintended side
effects that are caused by the RPKI validation process.
Wang, et al. Expires 2 December 2026 [Page 4]
Internet-Draft BMP-RPKI-MON-REQS May 2026
4. RPKI Configuration Monitoring
This section describes the monitoring of RPKI configuration on
routers, encompassing both RPKI data source status and RPKI-related
policy settings. These two aspects are closely correlated — both
describe how RPKI is set up on the monitored router — and are
therefore consolidated into a single RPKI_CONFIG message type (Type =
TBD1). This consolidation reduces the BMP namespace footprint and
enables natural correlation between data source state and policy
configuration.
4.1. RPKI Data Source Status
BMP SHOULD enumerate all sources of RPKI data on the monitored
router. These sources include RTR connections to RPKI cache servers,
iBGP sessions, eBGP sessions, local static configurations, and SLURM
local exceptions [RFC8416]. For each source, BMP SHOULD report a
common set of source-type-agnostic fields:
* A source type identifier indicating the kind of source (RTR, iBGP,
eBGP, static, SLURM);
* The reachability or connection status of the source (e.g., active,
idle, not applicable);
* The total number of RPKI records received or configured, including
ROAs and ASPAs;
* The timestamp of the most recent synchronization or update;
* The cumulative error count;
* Optionally, a CCR hash [I-D.ietf-sidrops-rpki-ccr] when supported
by the implementation, to enable verification of the RPKI dataset
version being used for validation.
In addition, source-type-specific parameters MAY be reported as
optional extensions within each source's TLV group:
For RTR sources:
* The RPKI cache's designation as primary or backup, including its
priority in the selection order;
* The version of the RTR protocol in use (e.g., version 0 [RFC6810],
version 1 [RFC8210]);
Wang, et al. Expires 2 December 2026 [Page 5]
Internet-Draft BMP-RPKI-MON-REQS May 2026
* The type of TCP connection established (e.g., plain TCP, TLS,
SSH);
* The IP address and port number of the cache.
For iBGP sources:
* The IP address of the iBGP peer providing the RPKI data.
For eBGP sources:
* The IP address and AS number of the eBGP peer providing the RPKI
data;
* The AS relationship between the eBGP peer and the current AS.
For static configuration sources:
* The timestamp of the last modification to the static
configuration.
For SLURM sources [RFC8416]:
* The number and type of local exceptions (prefix assertions and
prefix filters);
* The timestamp of the last modification to the SLURM file;
* Read/write errors of the SLURM configuration.
Note that CCR hash values, when they become commonly implemented, can
help a BMP consumer verify which version of the RPKI database is
being used for validation. However, CCR will require time to mature
and become commonly available. Implementations SHOULD include the
CCR hash as an optional field that can be adopted when ready. In
multi-source scenarios where RPKI data is acquired from multiple
sources simultaneously, per-source CCR hashes (where available)
provide pre-merge visibility, while the effective post-merge dataset
used for validation may be influenced by SLURM local exceptions.
4.2. RPKI Policy Configuration
BMP SHOULD report the RPKI-related policy configuration, which may be
applied globally (uniformly applied across all peers) or on a per-
peer basis (for example, only applied to the provider). The reported
information SHOULD include:
* The enablement status of RPKI validation;
Wang, et al. Expires 2 December 2026 [Page 6]
Internet-Draft BMP-RPKI-MON-REQS May 2026
* The enabled set of validation rules derived from RPKI data, such
as VRPs or ASPA entries;
* If enabled, the configured actions for routes with Invalid or Not-
Found states;
* SLURM local exceptions [RFC8416]: which RPKI validation rules are
locally overridden, including prefix assertions (locally added
VRPs) and prefix filters (locally removed VRPs). SLURM exceptions
SHOULD be treated as a first-class monitoring item, as they
directly shape the effective validation dataset used by the
router.
Note that since the size of the total validation rule set could be
really large, BMP could only convey the route features of enabled
validation rules. These features could be logical combination (AND/
OR) of a series of conditions (the origin ASes should be within a
certain set, the origin ASes should be a certain role such as the
customer, the rule source should only be static or iBGP, etc). The
network administrator could combine the features and per-route
specific information in the next section to obtain the total
validation rules.
4.3. RPKI_CONFIG Message Format
To convey the information described above, a new BMP message type
RPKI_CONFIG (Type = TBD1) SHOULD be defined. This message
consolidates what were previously separate RPKI_SOURCE and
RPKI_POLICY message types. The RPKI_CONFIG message SHALL use the
standard BMP common header followed by Type-Length-Value (TLV)
elements per [I-D.ietf-grow-bmp-tlv]. Data source status and policy
configuration are distinguished by Group TLV sub-types within the
same message. For data source information, TLVs SHALL be grouped per
RPKI data source, with each group using a Group TLV to index
Stateless parsing TLVs containing the common and source-specific
fields. A dedicated TLV within each group SHOULD specify the source
type to ensure consistency and scalability. For global policy
configurations, TLVs SHALL specify the validation rules and the
actions associated with each non-valid state (i.e., Invalid and Not-
Found), such as filtering, priority reduction, tagging, etc. For
per-peer policy configurations, the message SHALL include an
additional per-peer header, followed by TLVs that detail the RPKI
rules and policies specific to each peer.
Wang, et al. Expires 2 December 2026 [Page 7]
Internet-Draft BMP-RPKI-MON-REQS May 2026
5. Route Validation with RPKI
BMP SHOULD be extended to report both statistical summaries of
validation results on a per-peer basis and detailed validation
information for each route.
5.1. Validation Statistics
For each peer, BMP messages SHOULD include counts of received routes
categorized by their RPKI validation states. Rather than introducing
a dedicated RPKI statistics message type, it is RECOMMENDED that
RPKI-related statistics be reported using the existing BMP Statistics
Report Message [RFC7854] with new RPKI-specific Stat Type codes.
This approach aligns with the existing BMP extension ecosystem,
particularly the approach taken by [I-D.ietf-grow-bmp-bgp-rib-stats].
The new Stat Type codes SHOULD cover:
* The number of routes in each validation state: Valid, Invalid, and
Not-Found;
* Optional statistics, such as the number of routes filtered as a
result of RPKI validation.
This approach avoids the overhead of a new message type while
providing a natural extension point for future RPKI-related
statistics.
5.2. Per-Route Validation Report
For any individual route, since it may go through multiple types of
validations, and may hit multiple validation rules, BMP SHOULD report
not only the overall validation state, but also every validation rule
which is hit. Therefore, for per-route validation report, it is
RECOMMENDED that a dedicated Validation Report Message
RPKI_VALIDATION (Type = TBD2) be defined, by enhancing the original
Route Monitoring Message with additional TLVs. These TLVs should
describe:
* The overall validation state, including Valid, Invalid or Unknown;
* The types of validations the route goes through;
* The information of all relevant validation rules, including the
rule content (ROA entry for origin validation, ASPA entry for path
validation, AS group set for region validation, etc), the data
source, the expiration date, and the specific validation state for
each rule.
Wang, et al. Expires 2 December 2026 [Page 8]
Internet-Draft BMP-RPKI-MON-REQS May 2026
Note that if the overall validation state is Valid, the specific
validation state for every relevant validation rule should be valid;
if the overall validation state is Unknown, there shouldn't be any
relevant validation rule; if the overall validation state is Invalid,
there should be at least one relevant validation rule whose specific
validation state is Invalid.
6. Impact of RPKI Validation on Routing
BMP SHOULD report the consequences of RPKI validation on route
selection, with a particular focus on routes whose selection status
is altered by RPKI validation:
* Routes that are demoted due to RPKI validation (i.e., routes that
would have been selected as the best path without RPKI but are not
selected when RPKI is enabled);
* Routes that are promoted due to RPKI validation (i.e., routes that
would not have been selected as the best path without RPKI but are
selected when RPKI is enabled).
For each route affected by RPKI validation, the BMP extension SHOULD
report:
* The validation information, as detailed in the Route Validation
stage;
* The actions applied to the route following validation, such as
degradation of preference, attribute tagging, or exclusion from
the selection process.
Furthermore, the BMP message SHOULD include information about the
alternate best route:
* For routes demoted due to RPKI, the message SHOULD report the new
best route selected with RPKI enabled;
* For routes promoted due to RPKI, the message SHOULD report the
best route that would have been selected without RPKI.
This facilitates a direct comparison of routing decisions with and
without RPKI, thereby enhancing the understanding of RPKI's influence
on BGP path selection.
To enable per-route reporting of RPKI's impact on BGP routing, it is
RECOMMENDED that a dedicated Validation Impact Message RPKI_IMPACT
(Type = TBD3) be defined, by enhancing the original Route Monitoring
Message with additional TLVs, to capture changes in route handling
Wang, et al. Expires 2 December 2026 [Page 9]
Internet-Draft BMP-RPKI-MON-REQS May 2026
due to RPKI validation and policies. When a route is affected — such
as being dropped, deprioritized, or superseded by another route — due
to RPKI validation, such message could be triggered to report the
incident. This message SHOULD include:
* The prefix and attributes of the affected route;
* The RPKI validation state of the affected route;
* Details of all the relevant RPKI validation rules of the affected
route;
* The policy action enforced on the affected route (e.g., drop,
reduce priority, tag);
* Information of the alternate best route, including its prefix,
attributes, and RPKI validation state.
7. Relationship with Other Monitoring Mechanisms
The extensions defined in this document are designed to complement,
not replace, existing monitoring mechanisms for RPKI-related protocol
state. In particular, the operational state of the RPKI-to-Router
(RTR) protocol — including session management, protocol version
negotiation, cache server health, synchronization sequence numbers,
and PDU-level exchanges — is better addressed by YANG modeling and
streaming telemetry.
The division of responsibility is as follows:
* YANG / streaming telemetry: RTR session management, protocol
operations, cache server certificate details, and other
operational state of the RTR protocol itself;
* BMP (this document): what RPKI data the router has acquired (from
any source), what validation rules are in effect, how each route
is validated, and how validation outcomes change route selection —
i.e., the impact of RPKI on BGP routing.
The RPKI data source status reported by the RPKI_CONFIG message
([RFC8210]) is intentionally kept at a summary level — just enough
for a BMP consumer to know whether the router's RPKI data is current
and complete, without delving into RTR protocol internals. Source-
type-specific details (such as RTR protocol version or cache
priority) are provided as optional extensions for implementations
that find them useful, but are not required.
Wang, et al. Expires 2 December 2026 [Page 10]
Internet-Draft BMP-RPKI-MON-REQS May 2026
8. Security Considerations
8.1. Transmission Security
To ensure the integrity and authenticity of the transmitted
monitoring data on RPKI, BMP MUST support the following requirements:
* Protocol safety: BMP MUST employ either TCP Authentication Option
(TCP-AO) [RFC5925] or Transport Layer Security (TLS) to encrypt
the monitoring sessions.
* Data integrity: BMP should enforce mechanism like end-to-end
signatures to ensure the integrity of critical data such as ROA
validation result fields and AS_PATH change records, and validate
the integrity of the received data prior to extracting the content
of the data to prevent the propagation of tampered or corrupted
information. The signing/verification keys could be dynamically
derived from the RPKI certificate authority chain or managed
through other secure mechanisms, and form a cross-verification
mechanism with the source AS validation results of BGP UPDATE
messages (where applicable) to prevent malicious rollback or
tampering of the related monitoring data during transmission.
8.2. Operational Security
To ensure the extended BMP aligns with router's original
configuration, BMP MUST support the following requirements:
* Protocol transparency: The monitoring data collection must
strictly adhere to the "zero-intrusion" principle. For operations
involving the RTR protocol [RFC8210], only read-only interfaces
are permitted to retrieve certificate synchronization status, and
any modification to the router's local RPKI cache tree structure
is prohibited. The polling frequency of monitoring probes should
be restricted, and appropriate memory access layer protections
must be implemented to prevent cache reconstruction triggered by
monitoring data extraction. Additionally, the acquisition of
collected ROA validation records should not interfere with real-
time traffic processing.
* Forward compatibility: When the router does not enable the
monitoring function recommended by this standard, or when the
monitoring function fails, its native RPKI validation process
[RFC6811] and BGP decision logic must maintain full functional
consistency to prevent unintended routing policy changes caused by
the monitoring mechanism.
Wang, et al. Expires 2 December 2026 [Page 11]
Internet-Draft BMP-RPKI-MON-REQS May 2026
9. IANA Considerations
This document requires IANA to assign values for the following new
BMP message types and their associated TLVs:
* TBD1: RPKI_CONFIG — for reporting RPKI data source status and
policy configuration;
* TBD2: RPKI_VALIDATION — for reporting per-route RPKI validation
details;
* TBD3: RPKI_IMPACT — for reporting the impact of RPKI validation on
routing decisions.
Additionally, this document requires IANA to assign new Stat Type
codes for use within the existing BMP Statistics Report Message, to
report RPKI-related validation statistics.
The registration procedures for these assignments SHALL follow the
policy outlined in [RFC7854].
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
Wang, et al. Expires 2 December 2026 [Page 12]
Internet-Draft BMP-RPKI-MON-REQS May 2026
verification-23, 22 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-23>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
<https://www.rfc-editor.org/info/rfc6483>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2012,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/info/rfc6810>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/info/rfc8210>.
[RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified
Local Internet Number Resource Management with the RPKI
(SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018,
<https://www.rfc-editor.org/info/rfc8416>.
[I-D.ietf-grow-bmp-tlv]
Lucente, P. and Y. Gu, "BMP v4: TLV Support for BGP
Monitoring Protocol (BMP) Route Monitoring and Peer Down
Messages", Work in Progress, Internet-Draft, draft-ietf-
grow-bmp-tlv-19, 10 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-tlv-19>.
10.2. Informative References
[I-D.ietf-grow-bmp-path-marking-tlv]
Cardona, C., Lucente, P., Francois, P., Gu, Y., and T.
Graf, "BMP Extension for Path Status TLV", Work in
Wang, et al. Expires 2 December 2026 [Page 13]
Internet-Draft BMP-RPKI-MON-REQS May 2026
Progress, Internet-Draft, draft-ietf-grow-bmp-path-
marking-tlv-04, 25 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-path-marking-tlv-04>.
[I-D.ietf-grow-bmp-rel]
Lucente, P. and C. Cardona, "Logging of routing events in
BGP Monitoring Protocol (BMP)", Work in Progress,
Internet-Draft, draft-ietf-grow-bmp-rel-04, 3 September
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
grow-bmp-rel-04>.
[I-D.ietf-grow-bmp-bgp-rib-stats]
Srivastava, M., Liu, Y., Lin, C., and J. Li, "Advanced BGP
Monitoring Protocol (BMP) Statistics Types", Work in
Progress, Internet-Draft, draft-ietf-grow-bmp-bgp-rib-
stats-11, 17 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-bgp-rib-stats-11>.
[I-D.ietf-sidrops-rpki-ccr]
Snijders, J., "RPKI Signed Object for Cache Content
Reconciliation", Work in Progress, Internet-Draft, draft-
ietf-sidrops-rpki-ccr-02, 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-ccr-02>.
Authors' Addresses
Shuhe Wang
Beijing Zhongguancun Laboratory
Building 8, CourtYard 1, Zhongguancun East Road, Haidian District
Beijing
China
Email: wangsh@mail.zgclab.edu.cn
Mingwei Xu
Beijing Zhongguancun Laboratory
Building 8, CourtYard 1, Zhongguancun East Road, Haidian District
Beijing
China
Email: xmw@cernet.edu.cn
Wang, et al. Expires 2 December 2026 [Page 14]
Internet-Draft BMP-RPKI-MON-REQS May 2026
Yangyang Wang
Beijing Zhongguancun Laboratory
Building 8, CourtYard 1, Zhongguancun East Road, Haidian District
Beijing
China
Email: wyy@cernet.edu.cn
Jia Zhang
Beijing Zhongguancun Laboratory
Building 8, CourtYard 1, Zhongguancun East Road, Haidian District
Beijing
China
Email: zhangj@mail.zgclab.edu.cn
Wang, et al. Expires 2 December 2026 [Page 15]