Network Working Group S. Dikshit Internet-Draft Aruba Networks, HPE Intended status: Standards Track M. Srivastava Expires: 25 January 2027 Hewlett Packard Enterprise C. Lin New H3C Technologies 28 July 2026 A YANG Augmentation for Carrying BMP Telemetry in the Network Telemetry Message Envelope draft-dikshit-nmop-bmp-telemetry-message-00 Abstract [I-D.ietf-nmop-message-broker-telemetry-message] defines an extensible YANG envelope, "ietf-telemetry-message", for publishing collected Network Telemetry data to a Message Broker as part of a Data Mesh, together with a companion augmentation module, "ietf-yang-push-telemetry-message", that adds YANG-Push-specific subscription metadata to that envelope. The base document's prose explicitly anticipates the BGP Monitoring Protocol (BMP) [RFC7854] as a source of collected data flowing through this envelope (see the description of the "node-export-timestamp" leaf), but defines no "session-protocol" identity, and no companion augmentation module, for BMP. This document closes that gap. It defines a new YANG module, "ietf-bmp-telemetry-message", that (a) adds an "identity bmp" under the base module's "session-protocol" identity, and (b) augments "telemetry-message-metadata" with BMP-specific provenance: the monitoring station identifier, BMP per-peer header fields, BMP message type, and route-monitoring scope (network instance, RIB type, address family, and Route Distinguisher). It also documents how this module interoperates with the BMP YANG configuration and monitoring model [I-D.ietf-grow-bmp-yang] and with several BMP Statistics Report extensions ([RFC9972], [I-D.ietf-grow-bmp-stats-informational-tlv], [I-D.saum-grow-bmp-afi-safi-evpn], [I-D.smc-grow-bmp-route-change-stats], and [I-D.dikshit-grow-bmp-rd-scoped-rib-stats]) when their messages are republished to a Message Broker. 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 25 January 2027. 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. 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. Dikshit, et al. Expires 25 January 2027 [Page 1] Internet-Draft BMP Telemetry Message July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Gap in draft-ietf-nmop-message-broker-telemetry-message . 3 4. Relationship to Existing and In-Progress Documents . . . . . 4 5. BMP Telemetry Message Provenance . . . . . . . . . . . . . . 5 5.1. session-protocol Identity . . . . . . . . . . . . . . . . 5 5.2. BMP Session Provenance . . . . . . . . . . . . . . . . . 5 5.3. BMP Per-Peer-Header Fields . . . . . . . . . . . . . . . 6 5.4. Route Monitoring Scope . . . . . . . . . . . . . . . . . 6 5.5. Statistics Extension Marker . . . . . . . . . . . . . . . 7 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Use Case: Data-Product SLOs for BMP Statistics Pipelines . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . 12 10. Contributors and Acknowledgements . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction [I-D.ietf-nmop-message-broker-telemetry-message] defines the "ietf-telemetry-message" YANG module: an extensible envelope used at data collection to transform Network Telemetry [RFC9232] messages into a form suitable for publication to a Message Broker (e.g. Apache Kafka, Apache Pulsar) as part of an organization's Data Mesh. The envelope carries a Network Node Manifest, Network Telemetry protocol metadata (session-protocol, export/collection addresses and timestamps, sequence number), a Data Collection Manifest, network-operator labels, and the collected payload itself. A second module in the same document, "ietf-yang-push-telemetry-message", augments the envelope with YANG-Push [RFC8641] specific subscription metadata (subscription id, filter, transport, encoding, update trigger). The base module's "session-protocol" identity currently has three concrete identities: "yang-push", "netconf", and "restconf". However, the description of the "node-export-timestamp" leaf in that same module explicitly reads (emphasis added): "Timestamp when the Network Telemetry data has been exported from network element. This can be obtained in YANG-Push from event-time defined in draft-ietf-netconf-notif-envelope or in IPFIX from the export time in the message header as defined in RFC 7011 **or in BMP from the timestamp in the per-peer header as defined in RFC 7854**." In other words, the document's own text anticipates the BGP Monitoring Protocol (BMP) [RFC7854] as a legitimate source of Network Telemetry data flowing through this envelope, but no "identity bmp" exists to say so in the data, and no augmentation module exists to carry BMP-specific provenance the way "ietf-yang-push-telemetry-message" carries YANG-Push-specific provenance. This matters operationally because BMP is widely deployed specifically to export BGP RIB/session telemetry to collectors that frequently sit in front of the same Message Broker / Data Mesh infrastructure this envelope targets, and because a growing set of GROW working group documents extend BMP's Statistics Report message with additional per-AFI/SAFI, per-EVI, and per-policy- change-event counters (see Section 4) that would benefit from the same manifest/provenance discipline this envelope already provides for YANG-Push notifications: knowing which monitoring station collected the data, which BMP peer and RIB it concerns, and when it was collected versus exported, without having to parse opaque payload bytes to answer those questions. This document defines "ietf-bmp-telemetry-message", a companion augmentation module that closes this gap using exactly the same extension pattern the base document already uses for YANG-Push (an "sx:augment-structure" of "telemetry-message-metadata", plus a new identity based on "tm:session-protocol"). No change to the base module is required. 1.1. 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. 2. Terminology This document uses the terms "Message Broker", "Publisher", and "Receiver" as defined in [I-D.ietf-nmop-yang-message-broker-integration], and "Network Telemetry" as defined in [RFC9232]. It uses "Route Monitoring", "Statistics Report", "Peer Up/Down Notification", "Initiation Message", "Termination Message", and "Route Mirroring Message" as defined in [RFC7854]. It uses "monitoring station" as defined in [I-D.ietf-grow-bmp-yang]. 3. The Gap in draft-ietf-nmop-message-broker-telemetry-message See Section 1. In short: the base document's YANG model supports exactly one collection protocol family (YANG-Push, with NETCONF and RESTCONF also identified as identities but without a dedicated augmentation module of their own) even though its prose references BMP and IPFIX [RFC7011] as valid sources. This document addresses the BMP half of that gap; IPFIX is out of scope here but the same extension pattern applies and is noted as a companion opportunity in Section 4. 4. Relationship to Existing and In-Progress Documents This document builds directly on, and is intended to interoperate with, the following: * [RFC7854] defines BMP itself, including the per-peer header fields (Peer Type, Peer Flags, Peer Distinguisher, Peer Address, Peer AS, Peer BGP ID, Timestamp) reused in Section 5.3, and the message types reused in Section 5.2. * [I-D.ietf-grow-bmp-yang] defines the "ietf-bmp" YANG module for configuring and monitoring BMP sessions on the monitored router, including the "monitoring-station" identifier and the network-instance / RIB-type / address-family / peer hierarchy for route monitoring. This document's "monitoring-station-id" (Section 5.2) is intended to match the "id" key of that module's "monitoring-station" list when the monitored router and the collector are both administered by the same operator; see Security Considerations (Section 9) for the case where they are not. * [RFC9972] (published from [I-D.ietf-grow-bmp-bgp-rib-stats]) defines advanced, per-AFI/ SAFI BGP RIB statistics carried in BMP Statistics Report messages. * [I-D.ietf-grow-bmp-stats-informational-tlv] adds min/max/avg/ median informational TLVs to BMP gauge-type statistics. * [I-D.saum-grow-bmp-afi-safi-evpn] defines per-EVI EVPN BMP RIB statistics keyed by Route Distinguisher. * [I-D.smc-grow-bmp-route-change-stats] defines generic per-peer BMP statistics for route attribute changes caused by routing policy. * [I-D.dikshit-grow-bmp-rd-scoped-rib-stats] generalizes the per-EVI pattern above into an address-family-agnostic "RD-Scoped Statistics" container applicable to L3VPN, EVPN, and MVPN alike. When any of the above Statistics Report extensions are collected by a BMP monitoring station and republished to a Message Broker using the base envelope, this document's "route-monitoring-scope" container (Section 5.4) lets a consumer filter or route messages by Route Distinguisher, address family, and RIB type without parsing the (anydata) Stat Data payload, mirroring the filtering convenience "ietf-yang-push-telemetry-message" already provides for YANG-Push xpath/subtree filters. * [I-D.ietf-nmop-message-broker-telemetry-message] and [I-D.ietf-nmop-yang-message-broker-integration] are the base envelope and its architecture document, described in Section 1. A companion module for IPFIX [RFC7011], analogous in spirit to this document, is a natural next contribution for whichever author wishes to pick it up; this document does not attempt it so as to keep BMP and IPFIX concerns independently reviewable. 5. BMP Telemetry Message Provenance 5.1. session-protocol Identity This document defines: identity bmp { base tm:session-protocol; description "BGP Monitoring Protocol (BMP) as defined in RFC 7854."; reference "RFC 7854: BGP Monitoring Protocol (BMP)."; } A Publisher populating "ietf-telemetry-message:message" for data collected via BMP sets "telemetry-message-metadata/session- protocol" to this identity. 5.2. BMP Session Provenance "monitoring-station-id" identifies the BMP monitoring station configuration (Section 3.1 of [I-D.ietf-grow-bmp-yang]) under which the monitored router's connection to the collector was established. It is carried as an opaque string (matching the "monitoring-station/id" leaf type) rather than a leafref, because the collector's telemetry-message datastore and the monitored router's configuration datastore are, in general, different management contexts; see the discussion of collector identity versus BMP session identity in Section 4. 5.3. BMP Per-Peer-Header Fields Route Monitoring, Statistics Report, and Peer Up/Down messages in BMP all carry a Per-Peer Header (Section 4.2 of [RFC7854]). This document exposes the fields of that header that are useful for routing/filtering telemetry messages without payload inspection: peer type, peer distinguisher (Route Distinguisher, when the peer type indicates an L3VPN peer), peer address, peer AS, and peer BGP ID. The per-peer-header Timestamp field is intentionally NOT re-exposed here, since the base envelope's own "node-export-timestamp" already serves that purpose (see Section 1) once "session-protocol" is set to "bmp". 5.4. Route Monitoring Scope For Route Monitoring and Statistics Report messages, this document carries the network-instance, RIB type (adj-rib-in-pre/post, local-rib, adj-rib-out-pre/post, reusing the identities from [I-D.ietf-grow-bmp-yang]), and address family (reusing "afi-safi- type" from the same module) that the message concerns, plus an OPTIONAL Route Distinguisher for messages scoped to a specific VRF/ EVI/MVPN instance (as produced by [I-D.saum-grow-bmp-afi-safi-evpn] or [I-D.dikshit-grow-bmp-rd-scoped-rib-stats]). 5.5. Statistics Extension Marker An OPTIONAL "stat-extension" identityref names which registry a Statistics Report message's Stat Type belongs to (base [RFC7854], [RFC9972], the informational-tlv extension, the EVPN extension, the route-change-stats extension, or the RD-scoped-stats extension). This lets a Message Broker consumer route or dashboard messages by extension family without decoding the Stat Type/Stat Data payload itself, analogous to how "ietf-yang-push-telemetry-message"'s "module" list lets a consumer identify which YANG modules/revisions a push-update payload uses without parsing the payload. 6. YANG Module The following tree diagram summarizes the augmentation defined by this document (module: ietf-bmp-telemetry-message): augment-structure /tm:message/tm:telemetry-message-metadata: +-- bmp-session +-- monitoring-station-id? string +-- message-type identityref +-- peer-header | +-- peer-type? identityref | +-- peer-distinguisher? rt-types:route-distinguisher | +-- peer-address? inet:ip-address | +-- peer-as? inet:as-number | +-- peer-bgp-id? yang:dotted-quad +-- route-monitoring-scope | +-- network-instance? string | +-- rib-type? identityref | +-- address-family? identityref | +-- route-distinguisher? rt-types:route-distinguisher +-- stat-extension? identityref file "ietf-bmp-telemetry-message@2026-07-25.yang" module ietf-bmp-telemetry-message { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message"; prefix bmp-tm; import ietf-telemetry-message { prefix tm; reference "I-D.ietf-nmop-message-broker-telemetry-message: Extensible YANG Model for Network Telemetry Messages"; } import ietf-bmp { prefix bmp; reference "I-D.ietf-grow-bmp-yang: A YANG Data Model for BMP"; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing-types { prefix rt-types; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF NMOP Working Group (proposed)"; contact "Author: Saumya Dikshit Author: Mukul Srivastava Author: Changwang Lin "; description "This module augments the 'ietf-telemetry-message' envelope defined in I-D.ietf-nmop-message-broker-telemetry-message with provenance metadata specific to data collected via the BGP Monitoring Protocol (BMP), RFC 7854. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info)."; revision 2026-07-25 { description "Initial revision."; reference "RFC XXXX"; } identity bmp { base tm:session-protocol; description "BGP Monitoring Protocol (BMP) as defined in RFC 7854."; reference "RFC 7854: BGP Monitoring Protocol (BMP)."; } identity bmp-message-type { description "Base identity for BMP message types, RFC 7854 Section 4."; } identity route-monitoring { base bmp-message-type; description "Route Monitoring message."; } identity statistics-report { base bmp-message-type; description "Statistics Report message."; } identity peer-down { base bmp-message-type; description "Peer Down Notification."; } identity peer-up { base bmp-message-type; description "Peer Up Notification."; } identity initiation { base bmp-message-type; description "Initiation Message."; } identity termination { base bmp-message-type; description "Termination Message."; } identity route-mirroring { base bmp-message-type; description "Route Mirroring Message."; } identity bmp-stat-extension { description "Base identity for BMP Statistics Report Stat Type registries/extensions."; } identity base-rfc7854 { base bmp-stat-extension; description "Base Stat Types defined in RFC 7854 Section 4.8."; } identity rfc9972-bgp-rib-stats { base bmp-stat-extension; description "Per-AFI/SAFI BGP RIB statistics, RFC 9972."; } identity informational-tlv { base bmp-stat-extension; description "Min/max/avg/median informational TLV extension, I-D.ietf-grow-bmp-stats-informational-tlv."; } identity afi-safi-evpn { base bmp-stat-extension; description "Per-EVI EVPN BMP RIB statistics, I-D.saum-grow-bmp-afi-safi-evpn."; } identity route-change-stats { base bmp-stat-extension; description "Per-peer route-attribute-change statistics, I-D.smc-grow-bmp-route-change-stats."; } identity rd-scoped-rib-stats { base bmp-stat-extension; description "Address-family-agnostic RD-scoped statistics container, I-D.dikshit-grow-bmp-rd-scoped-rib-stats."; } sx:augment-structure "/tm:message/tm:telemetry-message-metadata" { description "Augments telemetry-message-metadata with BMP-specific provenance metadata."; container bmp-session { when "../session-protocol = 'bmp-tm:bmp'"; description "BMP-specific provenance for this telemetry message."; leaf monitoring-station-id { type string; description "Identifier of the BMP monitoring station configuration (RFC 7854 Section 3.1; see also the 'monitoring-station' list in I-D.ietf-grow-bmp-yang) under which this message was collected."; } leaf message-type { type identityref { base bmp-message-type; } mandatory true; description "BMP message type of the payload carried in this telemetry message."; reference "RFC 7854 Section 4."; } container peer-header { description "Fields from the BMP Per-Peer Header, RFC 7854 Section 4.2, relevant to routing/filtering telemetry messages without payload inspection."; leaf peer-type { type identityref { base bmp:peer-type; } description "BMP peer type."; } leaf peer-distinguisher { type rt-types:route-distinguisher; description "Route Distinguisher, present when the peer type indicates an L3VPN peer."; } leaf peer-address { type inet:ip-address; description "BMP peer IP address."; } leaf peer-as { type inet:as-number; description "BMP peer Autonomous System number."; } leaf peer-bgp-id { type yang:dotted-quad; description "BMP peer BGP Identifier."; } } container route-monitoring-scope { description "Scope of a Route Monitoring or Statistics Report message, mirroring the network-instance / RIB-type / address-family hierarchy of I-D.ietf-grow-bmp-yang."; leaf network-instance { type string; description "Network instance name."; } leaf rib-type { type identityref { base bmp:afi-safi-type; } description "Address family of the RIB this message concerns."; } leaf route-distinguisher { type rt-types:route-distinguisher; description "Route Distinguisher, when this message is scoped to a specific VRF/EVI/MVPN instance (see I-D.saum-grow-bmp-afi-safi-evpn and I-D.dikshit-grow-bmp-rd-scoped-rib-stats)."; } } leaf stat-extension { type identityref { base bmp-stat-extension; } description "For Statistics Report messages, identifies which Stat Type registry/extension the payload's Stat Data belongs to, without requiring payload inspection."; } } } } Note to WG: the tree diagram and module above use a placeholder reference to "bmp:peer-type" and "bmp:afi-safi-type" identities that would need to be confirmed/exported from [I-D.ietf-grow-bmp-yang] (that module currently defines "afi-safi-type" but the base BMP peer-type enumeration lives in RFC 7854 prose, not yet as a YANG identity; this document assumes the WG will expose it as one, and is happy to coordinate the exact identity names with the grow-bmp-yang authors, several of whom overlap with this document's authors and with draft-ietf-nmop-message-broker-telemetry-message's authors). 7. Use Case: Data-Product SLOs for BMP Statistics Pipelines Mirroring Section 4.2 ("Data Product Service Level Objective") of [I-D.ietf-nmop-message-broker-telemetry-message]: once BMP Statistics Report messages carrying RFC 9972 / route-change-stats / rd-scoped-rib-stats extensions are published through this envelope, a data consumer can compute end-to-end loss and delay for a given monitoring-station/peer/RD/AFI-SAFI combination using "node-export-timestamp" (from the BMP per-peer header, per Section 1), "collection-timestamp", and the time the message arrived at the consumer -- exactly as the base document already describes for YANG-Push -- without needing any BMP-specific parsing beyond this module's provenance fields. This also lets an operator build a single dashboard/alerting pipeline that treats YANG-Push and BMP derived telemetry uniformly at the transport/provenance layer, differing only in the "session-protocol" value and its associated augmentation. 8. IANA Considerations This document registers the following namespace URI in the IETF XML Registry [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG module in the YANG Module Names registry: Name: ietf-bmp-telemetry-message Namespace: urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message Prefix: bmp-tm Reference: RFC XXXX 9. Security Considerations This module inherits the security considerations of [I-D.ietf-nmop-message-broker-telemetry-message] Section 6 and of [I-D.ietf-grow-bmp-yang] Section 7.1. In addition: Correlating "monitoring-station-id" (Section 5.2) with an actual BMP session configuration requires that the collector and the monitored router be administered under a shared trust domain, or that the identifier be treated as an opaque, non-authoritative label when they are not. Implementations MUST NOT assume that a "monitoring-station-id" value is globally unique across administrative domains, and consumers processing telemetry from multiple organizations SHOULD additionally key on the Network Node Manifest (Section 3 of the base document) to disambiguate. The "peer-header" and "route-monitoring-scope" fields defined here expose BGP peering relationships, AS numbers, and VPN Route Distinguishers to any Message Broker consumer with access to the relevant topic. This is the same class of information already exposed by RFC 7854 BMP sessions themselves, but publishing it to a Data Mesh broadens its reach beyond direct BMP monitoring station connections; operators SHOULD apply Message Broker access controls (see Section 6 of the base document) commensurate with the sensitivity of routing topology and customer VPN identifiers. 10. Contributors and Acknowledgements Thanks to Ahmed Elhassany, Thomas Graf, and Paolo Lucente for [I-D.ietf-nmop-message-broker-telemetry-message], and to Camilo Cardona, Paolo Lucente, Thomas Graf, Benoit Claise, Dhananjay Patki, and Prasad S. Narasimha for [I-D.ietf-grow-bmp-yang], both of which this document builds directly on. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, June 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, December 2017. [RFC8791] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, June 2020. [I-D.ietf-nmop-message-broker-telemetry-message] Elhassany, A., Graf, T., and P. Lucente, "Extensible YANG Model for Network Telemetry Messages", Work in Progress, draft-ietf-nmop-message-broker-telemetry- message-05, 19 July 2026. [I-D.ietf-grow-bmp-yang] Cardona, C., Lucente, P., Graf, T., Claise, B., Patki, D., and P. Narasimha, "A YANG Data Model for BMP", Work in Progress, draft-ietf-grow-bmp-yang-09, 15 June 2026. 11.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol...", STD 77, RFC 7011, September 2013. [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, September 2019. [RFC9232] Song, H., Ed., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, June 2022. [RFC9972] (Published from I-D.ietf-grow-bmp-bgp-rib-stats), "Advanced BMP Statistics", RFC 9972, 2026. [I-D.ietf-nmop-yang-message-broker-integration] Graf, T. and A. Elhassany, "An Architecture for YANG-Push to Message Broker Integration", Work in Progress, draft-ietf-nmop-yang-message-broker- integration-13, 2 July 2026. [I-D.ietf-grow-bmp-stats-informational-tlv] Srivastava, M., Kolenchery, S., and C. Lin, "BMP Statistics Informational TLV", Work in Progress, draft-ietf-grow-bmp-stats-informational-tlv-00. [I-D.saum-grow-bmp-afi-safi-evpn] Dikshit, S., et al., "BMP RIB Statistics for EVPN", Work in Progress, draft-saum-grow-bmp-afi-safi-evpn-06. [I-D.smc-grow-bmp-route-change-stats] Srivastava, M., et al., "Generic Per-Peer BMP Route Change Statistics", Work in Progress, draft-smc-grow-bmp-route-change-stats-02. [I-D.dikshit-grow-bmp-rd-scoped-rib-stats] Dikshit, S., Srivastava, M., and C. Lin, "Route-Distinguisher-Scoped BMP RIB Statistics", Work in Progress, draft-dikshit-grow-bmp-rd-scoped-rib-stats-00. Authors' Addresses Saumya Dikshit Aruba Networks, Hewlett Packard Enterprise Email: saumya.dikshit@hpe.com Mukul Srivastava Hewlett Packard Enterprise Email: mukul.srivastava@hpe.com Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com